SQLite, давно хотел спросить

Если для тебя проверка типа поля при записи в БД - ерунда, то это твоя проблема.

по твоему, проверкой того, что в неё пихают, должна заниматься СУБД? Это не троллинг, я просто всегда думал, что этим должно заниматься уровнем выше, а на этапе вставки ты уже должен быть _уверен_, что твоё i - INTEGER, я не прав?

по твоему, проверкой того, что в неё пихают, должна заниматься СУБД?

До какого-то уровня - да, конечно. Называется это integrity, может, слышал?

на этапе вставки ты уже должен быть _уверен_, что твоё i - INTEGER, я не прав?

Ты прав. Но это совершенно нерелевантно, потому что не учитывает ошибок в программах.

Если для тебя проверка типа поля при записи в БД - ерунда, то это твоя проблема.

Обычно методы осуществляющие DML запросы к одной конкретной таблице базы данных сгруппированы в пределах одного файла или даже класса. Добавить одну проверочку аргумента можно тривиально. Или у тебя обычно не так?

См. выше.

Foreign key constraints это тоже интегрити. Но вот мускуль ее не поддерживает.

Вот уж к чему, а к sqlite я особо ненависти никогда не видел, даже на ЛОРе.

по твоему, проверкой того, что в неё пихают, должна заниматься СУБД?

До какого-то уровня - да, конечно. Называется это integrity, может, слышал?

слышал. по-русски: целостность. только при чём тут это?

на этапе вставки ты уже должен быть _уверен_, что твоё i - INTEGER, я не прав?

Ты прав. Но это совершенно нерелевантно, потому что не учитывает ошибок в программах.

по моему скромному опыту, если в БД должна записаться 2, то при ошибке запишется 3, 666, или ещё какая-то НЁХ. Но никак НЕ строка «жопа». А даже если и запишется, то оно будет интерпретировано как число, а не как строка. Т.ч. я не понимаю, как этот ваш TYPEOF() помогает искать _ошибки_ (sic! НЕ опечатки) в программе?

И?

И?

Давайте ненавидеть также и мускуль, че. За то что в нем можно случайно создать orphaned записи, например.

при чём тут это?

Отвлекись от забивания гвоздей и подумай.

по моему скромному опыту

Ты всё правильно понял.

при ошибке запишется 3, 666, или ещё какая-то НЁХ

Т.е. обнаружение попытки записи 3.666 в колонку с целым цислом не должна быть обнаружена СУБД?

Например, начинают делать множество «параллельных» запросов к sqlite. Или встраивают sqlite в многопользовательские программы.

Давайте ненавидеть также и мускуль, че

Ок.

Т.е. обнаружение попытки записи 3.666 в колонку с целым цислом не должна быть обнаружена СУБД?

это сложный вопрос. Ответ зависит от назначения СУБД, если это MySQL предназначенная для работы с пхп быдлокодерами - да, обязана. А вот для sqlite это часто просто не нужно, например на C ты попросту не в состоянии будешь передать не тот тип, даже если в качестве «обёртки» printf(3) (для «генерации SQL»). Просто там в типе int никак не может оказаться не только «3, 666», но и даже 3.666. Потому не очень понятно, зачем контроль типов нужен нормальным встраиваемым СУБД в нормальные ЯП?

Ну а в php этот вопрос можно тоже как-то решить, и это уже не проблема СУБД, а проблема ЯП, который в своих же типах разобраться не в состоянии.

Т.е. обнаружение попытки записи 3.666 в колонку с целым цислом не должна быть обнаружена СУБД?

это сложный вопрос

Это простой вопрос. Как только ты убираешь свои дополнительные условия, ответ становится очевидным.

Для сложных задач (где много данных), как я думаю.
Но не знаю примеров применения для таких задач SQLite.
Скорее как-раз тяжелые СУБД применяют где не надо, на вебе для обычных бложиков и т. д.

Или встраивают sqlite в многопользовательские программы.

Что здесь не так?

Поменял тип колонки@не обновил один запрос.

Например, начинают делать множество «параллельных» запросов к sqlite.

http://www.sqlite.org/draft/wal.html

Это простой вопрос. Как только ты убираешь свои дополнительные условия, ответ становится очевидным.

вопрос: нужны-ли дополнительные костыли для проверки типов данных, которые пишутся в БД? Ответ очевиден, ИМХО, костыли не нужны.

Для сложных задач (где много данных), как я думаю. Но не знаю примеров применения для таких задач SQLite.

«сложные» они разные бывают. бывает просто база большая.

Скорее как-раз тяжелые СУБД применяют где не надо, на вебе для обычных бложиков и т. д.

дык чем плохо применять MySQL для бложиков?

дык чем плохо применять MySQL для бложиков?

Жирно как-то, мне кажется.

Поменял тип колонки@не обновил один запрос.

ССЗБ. не меняй типы колонок. А если меняешь - меняй и код. Простая замена типа и в MySQL тоже не взлетит.

Жирно как-то, мне кажется.

ниразу. Особенно если 100500 бложиков в одной СУБД. ИМХО в самый раз.

Например, начинают делать множество «параллельных» запросов к sqlite

У меня сейчас с Фоксом из-за этого просто попа. Открыта тонна табов. Но стоит опция не загружать их. Стартует реально почти мгновенно (SSD!), но после этого десяток секунд не грузит контент активного таба, чем-то активно занимаясь с sqlite-базами.

Вообще, Firefox + sqlite — это очень, очень старая и грустная песня :) И у Хрома не намного лучше.

нужны-ли дополнительные костыли

Хромые в треде.

100500 бложиков

Не, это, понятное дело, другой вопрос.
Хотя... Все-равно, если посмотреть с точки зрения хостера, пожалуй, да.

нужны-ли дополнительные костыли

Хромые в треде.

ну раз хромые в треде, то пусть будет TYPEOF(), я не возражаю.

Не, это, понятное дело, другой вопрос.

если бложик на твоём локалхосте, то ничего с твоим компом не случится от mysqld.

Все-равно, если посмотреть с точки зрения хостера, пожалуй, да.

ага. Хотя вот на VPS с этим проблема(памяти не хватает, если дают 256, вот там sqlite в тему).

Когда одновременно несколько пользователей начинают писать/читать в базу, всё встаёт раком, потому что sqlite для этого не предназначен.

И к чему это?

И к чему это?

а ты почитай и подумай

особенно над вот этой строчкой:

«WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently. »

но после этого десяток секунд не грузит контент активного таба, чем-то активно занимаясь с sqlite-базами.

Похожая ситуация.

Но самый класс я встречал, когда какой-то умник настроил на сервере tracd(который и так не сильно шустрый), используя в качестве базы sqlite. Вот это были тормоза, так тормоза. :)

Ну и что? Но писать одновременно в несколько потоков нельзя, читать одновременно тоже нельзя. sqlite - это не многопользовательская база.

Ну и что? Но писать одновременно в несколько потоков нельзя, читать одновременно тоже нельзя. sqlite - это не многопользовательская база.

ок, та строка была слишком длинной, вот тебе нужная часть - «Reading and writing can proceed concurrently», и да - я этим пользуюсь, прекрасно параллелится

Reading and writing can proceed concurrently», и да - я этим пользуюсь, прекрасно параллелится

А как же:

The restriction on moving database connections across threads was relaxed somewhat in version 3.3.1. With that and subsequent versions, it is safe to move a connection handle across threads as long as the connection is not holding any fcntl() locks. You can safely assume that no locks are being held if no transaction is pending and all statements have been finalized.

Насколько я понимаю, параллельные транзакции тупо невозможны.

Я отлично понял эту строку. А теперь давай расскажи мне, как мне в sqlite одновременно, используя одно соединение, прочитать из десяти потоков что-то? А в это время одновременно записать в разные таблицы из десятка потоков?

И да. А ещё расскажи подробнее про операцию checkpoint.

в нем нет типов данных

Интересно, какие причины были сделать именно так? Нагуглил, что Richard Hipp - старый тиклер. Может в этом дело? По привычке запилил СУБД со слабой типизацией...

Насколько я понимаю, параллельные транзакции тупо невозможны.

возможны, только транзакции откладывают запись данных из WAL в саму БД, потому один «тормозной» поток может привести к тому, что лог станет огромным и sqlite выдаст ошибку, либо sqlite будет долго и нудно переносить данные

Интересно, какие причины были сделать именно так?

Особая порода тараканов в голове %)

А теперь давай расскажи мне, как мне в sqlite одновременно, используя одно соединение, прочитать из десяти потоков что-то? А в это время одновременно записать в разные таблицы из десятка потоков?

это не ко мне - это тебе ЯП выучить надо

Насколько я понимаю, параллельные транзакции тупо невозможны.

возможны

Как? Документация говорит: «You can safely assume that no locks are being held if no transaction is pending and all statements have been finalized», т.е. предавать соединение с БД в момент, когда транзакция не завершена, нельзя.

И да. А ещё расскажи подробнее про операцию checkpoint.

SQLITE_CHECKPOINT_PASSIVE

Checkpoint as many frames as possible without waiting for any database readers or writers to finish. Sync the db file if all frames in the log are checkpointed. This mode is the same as calling sqlite3_wal_checkpoint(). The busy-handler callback is never invoked.

достаточно?

Как? Документация говорит: «You can safely assume that no locks are being held if no transaction is pending and all statements have been finalized»

а это для всех «engine», т.е. не важно - используется ли журнал, wal, shared cache, memory etc.

А что, для WAL правила другие? Где они приведены?

А вот для sqlite это часто просто не нужно, например на C ты попросту не в состоянии будешь передать не тот тип

Кроме C есть еще и другие, в том числе тот же PHP c «быдлокодерами». Для РСУБД слабая типизация очень странная штука, ведь тип - это главный constraint для колонки. Может тогда и ключи выбросить, а уникальность строк и referential integrity вручную проверять.

А что, для WAL правила другие? Где они приведены?

в коде, там для wal две блокировки - на запись и на checkpoint (уже писал выше), т.е. потоки вынуждены ждать при записи, если кто-то уже пишет, чтение не блокируется

Foreign key constraints это тоже интегрити. Но вот мускуль ее не поддерживает.

Серьезно? Как им пользуются то вообще?

По-моему, ты заложился на какие-то детали реализации и единственный engine.