Есть еще более простое правило для тся/ться: помнить, что «ся» — это сокращение от «себя». «Может начаться революция» — «может начать себя революция» — во втором варианте никто не пропустит «Ь»?
Если речь только о регистрации пользователей в браузере, то валидность домена можно без регулярки проверить — через DNS — ajax-запросом на веб-сервер к скрипту, который делает DNS-запросы. Жаль что local-part адреса в реалтайме не проверить, т.к. это (SMTP-коннект к целевому серверу) уже могут быть не секунды, а десятки секунд, а в случае грейлистинга (на целевом сервере) и десятки минут.
Программирую больше 20 лет (мне сейчас 41, то есть до 50 не так уж и много осталось :) — и чем дальше, тем больше хочу продолжать программировать до конца своих дней.
А как заранее узнать размер этих «два буфера»? Размер буфера на передачу не может быть меньше TCP-окна (которое неизвестно до согласования этого параметра в конкретном соединении), т.е. 8Кб, к примеру, но на практике размер этих буферов в Linux вроде бы десятки килобайт (?) на каждое соединение. Т.е. 250 байт вообще погоды не делают в подсчете.
Да, WAL — оптимальный вариант, когда нужна приемлемая производительность без особого дрожания за целостность. Хотя в реализации WAL-режима в SQLite вплоть до текущих версий есть какая-то ошибка, из-за которой журнал иногда растёт больше заданного лимита (в многопоточном режиме использования). При этом всё продолжает работать без ошибок, но постепенно всё медленнее и медленнее, пока не переоткроешь БД в эксклюзивном режиме, тогда WAL записывается в основной файл, и всё нормализуется.
Опять же сошлюсь на свой (и тысяч клиентов нашего софта!) многолетний опыт использования SQLite на серверах: SQLite все-таки изредка не справляется с сохранением целостности БД при сбоях питания или зависаниях железа (перегрев). Независимо от настроек синхронизации и режима журнала. Притом, что у нас он используется на Windows, где от NTFS ожидается дополнительная помощь в этом деле… Но увы. Не зря в SQLite есть backup API :)
Много лет использую в SQLite кодировку windows-1251 вместо UTF-8. Никаких проблем с парсером это не создаёт. Но вот операции LIKE работают неправильно (не понимают регистр русских символов, конечно) и FTS-раширения тоже работают неправильно. Не стал переделывать collations, а вместо этого в FTS-индексах привожу всё к lowercase, и это снимает проблему.
Точно. Читая книжку, сначала соглашался с автором, но чем дальше читал, тем более казалось, что автор не прав. Наверное профессия у него не ITшная. А нашем деле без некоторых ловушек никак нельзя :)
Вот в том-то и дело, что функции, которые как бы ожидаются от ОС (и которые в тех же виндах еще года с 1990го, а скорее и с 80х), тут еще «надо написать».
А, извините, я просто не понял вопрос. Я думал, что в массиве char* у вас исходные данные (значения полей в каком-то из традиционных текстовых форматов), а не бинарник файла БД. В этом случае тоже можно выкрутиться — формат известен www.sqlite.org/fileformat.html — но действительно намного проще будет просто записать массив в файл и открыть как файл штатным sqlite3_open.
Да, тип поля, конечно, хранится в БД. Структура файла SQLite хорошо документирована — www.sqlite.org/fileformat.html Типы нужны для 1) конвертации в читабельное состояние при выводе результатов, 2) в SQL-функциях над несовместимыми типами производится конвертация (ну то есть если к строке прибавлять число, то оно конвертируется в число, а не в виде blob'а пристыковывается). Но при операциях над одним типом (наиболее массовые операции — всякие там SUM и прочая арифметика) никакой конвертации, поэтому не ухудшает производительность.
Интерфейсную часть в 6й версии взяли от MS Visual Studio. Так что Сишный код теперь в оболочке пишется лучше, чем во любых старых контроллерных IDE.
> Вот эта картинка хорошо описывает случай излишней зависимости от чужого мнения.
На эту тему наш отечественный Гуру (Толстой) хорошо высказался: www.rulit.net/books/dnevniki-read-73798-4.html