Опубликован релиз SQLite 3.37, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56244
Это лучшая встройка в мире
Жаль что не на расте
Жаль что не на хаскеле
Ни на том ни на другом такого ПО никогда не будет, к счастью.
На Golang зато можно. Тот же boltdb на столько идеален что ему даже больше не надо выпускать новые версии.
А вот этого не надо (с)
Надо, Федя, надо! (c)
Как вы пришли к такому выводу? И почему это к счастью?
А слабо на BrainFunc :))
brainfuck это пишеццо
согласен, палочка-выручалочка
Без питона, SQLite и gnuplot это было бы невозможно - /v19
Вы о чем ?
Закусывать надо, - обязательно, иначе ваши обороты речи, - не поддаются анализу
Браузер ведь использует сабж? Как сделать, чтобы когда место кончается, он не рассыпался и не удалял все настройки аддонов и вкладок? Я внезапно обнаружил, что временные файлы с меги (почему они не удаляются, кстати?) выжрали всё место в хомяке, и почти все программы умерли и потеряли все данные.
Нет, вся беда именно в том что смузихлебы ниасилили сабж.
Браузеры нынче используют интуитивно приятные этим макакам смузи-форматы, необратимо портящиеся и не подлежащие восстановлению, от sqlite отказались почти полностью. Но ты с этим ничего сделать не можешь.> Как сделать, чтобы когда место кончается, он не рассыпался и не удалял все настройки аддонов и вкладок?
попросить мамку укупить тебе компьютер пожырнее.
Я вот не знаю что ненужное надо сделать чтобы кончилось место не на сервере без присмотра десять лет, а на машинке где я работаю.
Скулит тоже портится необратимо без особых нагрузок.
> Скулит тоже портится необратимо без особых нагрузок.А вон фряшный пакетник pkg, на sqlite - почему-то не портится.
Просто у обезьянок оно всегда так - сначала "Пишем код! Быстрей-быстрей! Да хвостом шифт зажимай!", а потом - "оно само, не виноватая я!".
Ну так чего ты хочешь - написано-то на немодных сях, а не каком игого с коровоутинами, пытающимися параллельно жевать одну и ту же соломину и давящимися в результате, и параллельная запись не предусмотрена от слова вообще.Вот мразила уже освободилась от этой устаревшей плесени, и целиком почти перешла на нескучные json форматы. А потом ты гуглишь "у меня перестали запоминаться размеры окон, как починить?" - и находишь такое, что хоть стой, хоть падай.
Заметим, для этого совершенно не требуется чтобы на диске кончалось место, оно само.
> почти все программы умерли и потеряли все данныеА что ещё ждать от недобазы?
Что значит "недобаза" в твоём лексиконе? Видимо, на каждый чих ты Оракл привык разворачивать в кластерной конфигурации. Да? LOL!
Ты наверно к каждой микротулзе по скулю привязываешь. LOL!
А ты точно не читатель, малыш. И с памятью у тебя явные проблемы. Напомню. Чел выразил недовольство тем, что SQLite - это "недобаза". Вот мне и хотелось бы понять, какую бы он СУБД использовал бы в таком случае.
Это не проблемы с памятью, он просто к тебе относится как к гoвну
На любом предприятии УЖЕ есть некая SQL - от pgsql, MySQL, MSSQL, DB2, Oracle... Создать в ней нужную БД - дело 2х минут. Заодно она сразу угодит в мониторинг, план бекапов и т.д.А вот со всякими SQLite, MS access, lo base, kexi и прочи локальным г-ном - возникают проблемы... С бекапом, мониторингом, контролем доступа и т.д.
Была одна неплохая опенсоурснвх разработка - содрано с лучшей персональной СУБД - FileMarker, но в качестве движка - использовала pgsql... Жаль что лет 10 как сдохла
На любом достаточно большом предприятии их десятки.> А вот со всякими SQLite, MS access, lo base, kexi и прочи локальным г-ном - возникают проблемы...
> С бекапом, мониторингом, контролем доступа и т.д.вон из профессии!
Десятки только там где нет планирования.
> На любом предприятии УЖЕ есть некая SQL - от pgsql, MySQL, MSSQL,
> DB2, Oracle... Создать в ней нужную БД - дело 2х минут.Ну, давай, предложи "тупым" андроиду и апплу поменять в телефонах sqlite на твоих тяжеловесов...
А зачем в телефонах sqlite, да и вообще sql? Конфиги хранить да логи? :)
> А зачем в телефонах sqlite, да и вообще sql? Конфиги хранить да
> логи? :)Вот я когда не в теме, то стараюсь варежку держать закрытой, чтоб глупо не смотрется, того и вам желаю
Так чего же ты не сейчас открыл-то?
> Так чего же ты не сейчас открыл-то?Ну, так потрудись поискать значимость sqlite на телефонах, тогда будет понятно - "почему"
> значимость sqlite на телефонахОчевидно что нулевая.
> А что ещё ждать от недобазы?троллим потихоньку ?
Дожились. А когда это в скулит альтер тейбл зовезти успели ?
жаль что лицензия не GPLv2, в ядро не вставить. и язык запросов не раст, небезопасно.
> жаль что лицензия не GPLv2, в ядро не вставить.Суть публичного достояния же в том, что можно вообще всё: и все копирайты убрать, и вписать себя единственным автором, и выбрать любую лицензию.
> требующим обязательного указания типа при объявлении столбцов и применяющим строгую проверку соответствия типовМаятник пошёл в обратную сторону? Народ нахавался динамического преобразования чего угодно во что угодно и теперь разрабы везде будут внедрять строгую проверку типов?
Нет, просто SQLite изначально был очень плохо спроектирован, до этого "динамизма".Но альтернативы, по-сути, нет для offline-first приложений.
Изначально не планировалось, что SQLite будет куда-то активно внедряться, был написан просто для удобства работы с небольшими наборами данных. Но проект внезапно взлетел и стал невероятно популярным. На slashdot'е было интервью с автором.
Так всегда было :) Опытные зубры работают со статическими типами. Набегают смузихлёбы и начинается пестоно-вакханалия или жаболожство, потом всё это rовно падает, заказчик воздымает руки и пендалями прогоняет пи%%%%сов на мороз. И снова приходят зубры и переписывают всё как надо. :)
Это если у заказчика есть кто-то толковый. Часто просто докупают железо, переходят на бОльший план хостинга, а косяки подпирают костылями и подмазывают соплями.
И для заказчика это норма, он просто не представляет, что можно как-то по-другому.
Джава-то как раз строго-типизированный язык.
Так. В проде можно использовать? Какие камни будут если 10_000 посетителей в сутки
Чем тебя текстовые файлы не устраивают?
Как вы представляете себе форум на текстовых сайтах?
*Файлах
> *Файлахотлично представляю - унаследовал такой. В каждом сообщении есть линки на все ответы на ответы на ответы на это сообщение. При появлении нового сообщения в теме - все это цепочкой обновляется.
И в принципе даже бы и работало, подумаешь обновить тысячу файлов примитивным скриптом - упс...как удалить сообщение спаммера, ссылка на которое уже добавлена в тысчонку файлов? А никак...Что делать если корневой индекс повредили? Сушить ласты...
Ну и так далее.
А так даже и работало, с 2000 по 2009й, что-ли.
Бггг, кто-то жёстко говнокодил.
Просто тему в один файл запихать было бы намного эффективнее.
И даже дописывать можно без особого изнасилования мозга.
> Просто тему в один файл запихать было бы намного эффективнее.теперь спам вообще нельзя удалить без переписывания всего файла в хз сколько мегабайт (а те кто в этот же момент пытаются добавить - еще подождут)?
Эффективность! Подай заявление на перевод в девляпсы.(Видимо про дерево реплаев ты не, не слышал? У тебя все форумы были плоские, хер угадаешь кто и на что отвечал?)
Ты просто не догнал.
Что значит "нельзя". Дописываешь в хвост <ID>=null, и всё, нет поста, при разборе файла он сотрётся. А внутри не сотрётся, для истории, в админке можно всё показать.
Дерево ответов? А что мешает в пост ID ответа-то писать? При загрузке файла всё это точно так же разберётся.
В хвост чего, у тебя ж вся тема в одном файле. Нет, ты не успел, это не последнее надо удалить, а уже пятнадцатое от конца (и ему еще и ответили).> А что мешает в пост ID ответа-то писать?
то что ты никогда не видел нормального threaded view. К сожалению, я бессилен тебе в этом помочь - tin то ты может еще и соберешь, а где найти живые ньюсгруппы с активной перепиской и сотнями участников, чтобы посмотреть как это работает - понятия не имею. Наверное, в прошлом. Современные бюллетинборды пишут м-ки для м-ков. Там именно что темы на вес золота и заводить новые должны специальные люди (ну потому что на всяких торренстру для которых и предназначены нынешние поделки, это нормально)
Причем тин-то локальный, всю необходимую информацию кэширует и индексирует на стороне пользователя. (а первоначальное ее всасывание, кстати, было сильно небыстрым) Но у нас же веб, персистентность не в моде. На каждый переход к следующему мессаджу - будешь сканить всю базу.
Вся тема в одном файле не означает, что нельзя новые данные писать в хвост файла, не?Пример:
{post_id: 1, text:"Пост 1",date:"2021-01-01 01:01:01",...}
{post_id: 2, text:"Пост 2",date:"2021-02-02 02:02:02",...}
{post_id: 1, deleted: true, date:"2021-03-03 03:03:03"}Мысль, думаю, понятна.
В итоге переписывание файла целиком сводится к минимуму, только на сжатии.
Более того, можно писать всякие гзипованные варианты, только сериализацию взять соответствующую.
Ну хосспаде, повторюсь, постгря так и делает. А отдельно держит индекс чего-куда.
> Вся тема в одном файле не означает, что нельзя новые данные писать
> в хвост файла, не?
> Пример:
> {post_id: 1, text:"Пост 1",date:"2021-01-01 01:01:01",...}
> {post_id: 2, text:"Пост 2",date:"2021-02-02 02:02:02",...}
> {post_id: 1, deleted: true, date:"2021-03-03 03:03:03"}
> Мысль, думаю, понятна.угу, теперь файл надо еще и целиком сканировать чтобы убедиться что первый пост не удален.
Ну да, ты еще изобрел к нему индексы. Просто прекрасно. Еще надо будет изобрести реиндексатор и контроль целостности (а то вдруг что-то пошло не так, индекс обновился, файл нет)
Продолжаем-продолжаем изобретать квадратное колесо?> Ну хосспаде, повторюсь, постгря так и делает. А отдельно держит индекс чего-куда.
Да, именно поэтому она - г-но.
Сколько там все обещали-обещали запритить-запритить vacuum full ? Но десять лет что-то ну никак нишкладывалось. Теперь делают вид что ничего такого и не было, и вообще "чем вам мешает".
Не надо файл целиком сканировать, у большинства форумов постов не наберётся столько в треде, чтобы его целиком не вгрузить один раз в память. А если наберётся - тогда да, просканировать здоровыми блоками. Чудес не бывает, и волшебная RDBMS тоже сканирует файлы :)
Если контент здоровый - можно ещё со сканированием упростить: достаточно перед данными псто (возможно сжатыми) хранить их длину. Но это уже не про форумы.
> Не надо файл целиком сканировать, у большинства форумов постов не наберётся столько
> в треде, чтобы его целиком не вгрузить один раз в память.а с чего ты взял, что один раз? Гугель зайдет на огонек - и вгрузит тебе по самые гланды со всего своего пула. Оне последние лет десять по другому работать разучились.
Threaded view генерится из любого набора данных элементарно, главное не вгружать по одному посту, а вгрузить весь тред (треды) целиком, и далее собрать дерево ID. Операция совершенно копеечная.
И да, не надо блджад сканить всю базу.
Много постов, лень всё дерево загружать? Индексируй это, и загружай только индекс. А дальше уже решай, чего тебе из него надо. RDBMS так и работают, т.е. всё это уже сделано, и можно не костылить. Но понимать, как сделано - надо.
> И да, не надо блджад сканить всю базу.
> Много постов, лень всё дерево загружать? Индексируй это, и загружай только индекс.
> А дальше уже решай, чего тебе из него надо. RDBMS так
> и работают, т.е. всё это уже сделано, и можно не костылить.именно. То есть ты наконец-то понял что изобрел велосипед с квадратными колесами?
Да нет, я изначально пишу, что в RDBMS всё это уже сделано.
Но это не значит, что при _серьёзной_ надобности я не сварганю RDBMS замену.
А вот тем, кто всецело на RDBMS полагается, и ничего окромя не умеет - ну, курить в сторонке.
Немного оффт.
Живые группы есть на eternal-september.org
В разные периоды то более-менее живые, то скорее неживые.
На этом понять смысл и преимущества тредовой читалки не получится. Они хорошо видны от 1000 постов в сутки - когда в принципе и невозможно читать их все, и незачем.
В nntp linux-kernel ещё есть. Который как-раз показывает всю ущербность tin'a - и его тормозные кэша, и прочие кривые фильтры с непонятным скорингом. А отсутствие limit pattern как в mutt'e - вообще делает его малополезным на чём-то с большим трафиком.
Не, ну fido7.* читать пойдётЪ, да.
https://forum.combats.com/?
от неосиляторов древовидной структуры. Это даже не 2000й, это 89й, ну да, ну да, фидо с ее глупыми "lastread" и 640k enough.
Да легко, вообще делать нечего.
1 тема = 1 файл, сообщения append'ятся
Глобальные индексы тем и поиска таким же append-файлом.
Удаление сообщений через дописывание ID=null.
Периодически компактирование, которое ничем не хуже вакуума в постгре.
> 1 тема = 1 файл, сообщения append'ятсятемы создаются модератором после стасорока обращений и ритуального танца.
Структура не нужна, да и зачем она форуму с тремя посетителями в году. Они и так помнят ответом на какой ответ является этот ответ.
"Ответом на какой ответ является этот ответ" - просто поле в данных поста, оно не требует специального обращения при хранении.
А теперь выведи мне всю цепочку сообщений, к которой относится это сообщение - вот до корневого.(ну или задачка попроще, просто покажи с чего все началось, я там дальше сам посмотрю, может мне другую параллельную подветку надо было)
Оно еще как требует специального обращения, если к тебе ходят не полтора васяна.
Элементарно. Thread id в сообщении есть всегда. Референс на предыдущий ответ тоже.
В данном случае весь Thread - в одном файле (ну или в нескольких разбитых для оптимизации, кому как удобнее). Вгрузили и вывели.
> Элементарно. Thread id в сообщении есть всегда. Референс на предыдущий ответ тоже.хаха. А что такое "thread" ? На любое письмо может быть два реплая, каждый стартует новую ветку, одна вообще полуоффтопик, другая ушла на другую тему. Вот тебе _нормальная_ тредовая модель.
А не треды создаются особами приближенными к Б-гу Императору, а внутри у них линейная каша.
> В данном случае весь Thread - в одном файле (ну или в
И смысла в этом нет никакого.
Я же говорю - у тебя голова промыта торренсрами которые не для общения предназначены.
Поэтому и сдохли бюллютеньборды в качестве средства общения (ну, в том числе). Остались только для раздачи вареза.
Разьве что wwwthreads делали люди, еще помнившие те ньюсы (или фидо, или что там они помнили, но вряд ли придумали с нуля). Но они давно умерли или ушли на покой.
Вгружается весь тред до корня. Или весь целиком, или индекс. Строится из линейной структуры ID<->ID деревце - не бог весть какая операция. Дальше выводится. Напоминаю, мы в рамках форума, пара сотен тысяч постов в треде "с корня" вряд ли наберётся.
Больше того, для RDBMS такая задачка - тоже не из самых лёгких. Проще бывает вгрузить листы ID<->ID по source thread ID, и дальше их уже кодом в дерево обработать. Рекурсивные запросы много где ныне есть, но эффективность у них, @#$...У меня примерно аналогичная задачка, только там не дерево, а суперпрефиксы по телефонии. +1 +1 123, +1 123 456, и вплоть до полных номеров. Их надо как раз таки тред-подобным образом агрегировать.
> телефонии. +1 +1 123, +1 123 456, и вплоть до полных
> номеров. Их надо как раз таки тред-подобным образом агрегировать.агрегировать - не то же самое что иметь доступ к древовидной структуре. Сам по себе элемент +1 123 456 никому не нужен и никакая строка в таблице традиционной базы данных ему бы не соответствовала - просто нечего в ней хранить.
Дарю:
with recursive
thread(id,replyid,level) as (
select id,replyto,0
from messages where id=$msgid
UNION ALL
select
messages.id,messages.replyto,level+1
from messages,thread where replyto=thread.id
ORDER BY 3 DESC
) select * from thread,messages
where messages.id=thread.id ;обратить внимание, что в этой базе нет никаких персистентных thread id - за ненадобностью. Тред может начинаться (и начнется) в любом месте, а не от корня (за десять лет тот корень забыт всеми и давно уже о другом болтают)
"корень" отличается лишь тем что у него нет replyto и выше него некуда прыгнуть.
Да, это sqlite. Причем, как и полагается, какой-то совершенно доисторической версии.
Лет пять назад еще вполне себе работало.
Ды щаз, не нужен.
К этим элементам тарифы прибиты, и маршрутная информация.Про запрос выше могу сказать только что по нагрузке будет легче целиком вгрузить :D
И нет, никаких специальных телодвижений там до появления тредов на больше памяти, чем один одновременный клиент может выжрать, не требуется.
Я просто очень даже в работе оперирую структурами, которые сильно превышают объём RAM вообще.
Там приходится и линейную дозапись блоков в файлы делать, и вгружать блоками.
И нет, RDBMS там в конкретной задаче я пробовал, это бессмысленно, много обработок и специфичные свёртки (prefix-based coalescing).
SQLite кстате тоже есть )
дык на таком сайте прям щас сидишь
Не слышал про DokuWiki? PhpBB форум может работать работать на текстовых файлах и много других созданных во времена web 2.0. Ничего плохого в этом нет.
Ничего хорошего - тоже. Оно конечно работает, но... мягко говоря не стабильно.Но SQLite тут не поможет. Особенно шикарна связка SQLite+какой-нибуть язык с GIL, типа пихтна или риби... Spiceworks не даст соврать.
Поначалу таже такое тупое решение работает. Проблемы начинаются обычно в середине, когда чела тупо попросили отсортировать по дате. :) "Текстовые файлы" годятся для вейпер-шопа с 3 позициями, а для форума нужна нормальная база.
А в чём проблема сортировки-то? Загрузил, и ворочай как хочешь. БД примерно то же самое делает.
В самом худшем случае можно коротеньких индексных файлов докинуть, по 1 рекорду на 1 рекорд, просто чтобы всю портянку целиком не грузить. Если ещё сильнее изгольнуться - в индексные файлы можно поинтер писать внутрь основного, чтобы сразу с нужного места вгружать.Единственное что, при наличии RDBMS - всё это называется "изобретение велосипедов" - там всё это уже нормально сделано.
> А в чём проблема сортировки-то? Загрузил, и ворочай как хочешь.и после пятого пользователя кончается почему-то память. Ну да, ну да.
Но давайте еще добавим индексов и переизобретем sqlite заново - с квадратными колесами на этот раз.
Ты не поверишь, вот даже для опеннета такого движка хватит, и ничего нигде не кончится.
Память скорее кончится во всяких жабомонолитах, которые не знают, что такое загрузка данных по запросу, и пытаются всё в памяти удержать.
В чем проблема отсортировать по дате, если файлы на одной из версий reiserfs?
Я б не ставил на ссыкулит. Есть же вполне легковесные базы типа Postgres или даже Interbase (там ещё какие-то опенсорсные открытые форки были). MySQL опять же. Чем "стандартнее" СУБД, тем меньше от неё ожидается проблем.
Куда уж стандартнее?
Почти на каждом компьютере или телефоне есть несколько баз sqlite
Несколько? В каждом приложении.
Это однопользовательский движок. В нём нет (практически нет) реализации изоляции транзакций. Ну кроме сериализации через ожидания.
> Это однопользовательский движок. В нём нет (практически нет) реализации изоляции транзакций.
> Ну кроме сериализации через ожидания.И вот это единственная реальная претензия к автору. Почему он не захотел осилить sysV ipc, сделав вместо них файловые локи - вопрос риторический, под виндой нет никакого sysV.
(причем в самых последних версиях ipc появился, linoops only, но не для изоляции, увы - похоже, такая идея автору в голову если и приходила, то никого там уже не застала, расстроилась и ушла)
Ну венды тогда на военных кораблях ВМС США не было. И сейчас, наверное, нет.
Эммм... мне казалось, история с заклинившими орудиями кресейра должна была войти уже в школьные учебники? "Персонал проинструктирован - ноль в это поле не вводить!" (У nt3.1 не оказалось обработчика прерывания по делению на ноль на платформе, кажись, mips)Сейчас, наверное, нет. Зачем платить ms, когда можно линoops нахаляву побольше, побольше!
К слову, не так страшны 10 тыщ леммингов в сутки, как 1000 хакеров в 1 секунду. :) Тут надо смотреть на пиковую загрузку. На простом .NET/C# и sockets (самый обычный, connect-send-receive) я держал 120 клиентов в секунду. С вебом может быть посложнее, но тут надо смотреть бутылочное горлышко и устранять.
С пиковой загрузкой в случае простых не-realtime сервисов решается отдачей "please wait" всем, кто не влез. Чуть подождут, и влезут.
Зачем? Любая транзакционная СУБД с этим справится без сериализации.
> Зачем? Любая транзакционная СУБД с этим справится без сериализации.ну да, ну да - ведь никогда ж такого не бывает что два пользователя обновляют одну и ту же строку.
Ой... алярма, кнутователь бежит махая кнутом - у нас опять "все пависла в базе локи!"
Бывает и является простой рутиной, разрешаемой бизнес-правилами. Как-бы, большинство производственных баз апдейты делают на рипитэбл рид или вообще на рид коммитэт и как-то проблемы потерянных обновлений решают. В mvcc-режиме локов не будет -- будут откаты из-за коллизии обновлений. В блокирующем гуане мамонта, вроде старых МС Сиквелов, да, дэдлоки будут, но там тоже это всё решаемо.
10000 посетителей или обращений?
Если второе - можно конечно, это один штука в 8.64 секунды.
А то может каждый посетитель по 20 запросов в секунду хочет, тогда нельзя.
> But apart from the extra STRICT keyword, the underlying file format of the database is identical.Нахрен не нужно. Это значит там всё ещё хранят схему для каждой отдельной записи. То есть оверхед. Если у тебя много записей - то много оверхеда. Если тебе в одной колонке поле нужно хранить всего один байт, то оверхед на хранение типа этого байта будет как сам этот байт (тип храрится в varint, а он is between 1 and 9 bytes in length).
STRICT - тупо сахар для неосиляторов.
Что же до оверхеда - всё это мелочи по сравнению собственно с глобальным индексом записей.
Именно так - мурзила и кто там еще девушка ужынает не справилась с битьем по рукам обезьянок, все равно умудряющихся засунуть строку вместо числа и потом падающих на попытке ее использовать как число.Проще и дешевле дэушка утанцевать в сторону добавить проверку в саму библиотеку, чтоб по лапкам попадало автоматически и всегда. Считайте это еще одним constraint, оно скорее всего и механизм использует тот же самый.
Что до оверхеда, то он нулевой.
"Add the --safe command-line option that disables dot-commands and SQL statements that might cause side-effects that extend beyond the single database file named on the command-line. "Плохо понимаю, зачем ограничивать _CLI_, ну да ладно.
>Плохо понимаю, зачем ограничивать _CLI_За скриптингом.
Квалификация скуль разработчиков вынуждает накладывать на них возможность защиты от дурака.
SQLite это не СУБД!
Не мешай людям мечтать!
SQLite это настолько не Unix way, что аж зубы сводит...
У него же бинарный формат файла, а в нем - конфиги хранят!
И эти же люди - жалуются на реестр...
Что поделать, кирпичом пытаются гвозди забивать.
У нее один плюс - в теории ее всегда можно выкинуть и без особых проблем заменить на полноценную СУБД. С минимальными переделками.
Скорее не переделками, а перделками. И не минимальными, а густыми и сочными.
Да тут фанатики почище раста. Все на стороне скуля.
В смысле? Если тебе нужен sql db - используй полноценную СУБД. А вот если тебе не нужна полноценная СУБД - отличный повод задуматься, а нужен ли тебе именно SQL?
Нет никакой обязательной связи между Сиквелом и СУБД. Сиквел просто удобный способ манипулировать данными. Всё. Удобнее, а практически всегда удобнее, использовать декларативный реляционный подход? Вот тебе, держи и пользуйся. Нужна многопользовательская среда с транзакциями, бэкапом, репликациями и т.д. и т.п.? Тогда нужно что-то потолще.
Да ну?> SQL (ˈɛsˈkjuˈɛl; англ. structured query language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.
У тебя во рту тоже есть язык. Но если его оттуда изъять он языком быть не перестанет. Синтаксически.
Сиквел это один из диалектов, реализующих (не в полной мере) реляционную исчисление (или алгебру). Поверх чего реализующих это уже вопрос конкретной реализации.
> Сиквел это один из диалектов, реализующих (не в полной мере) реляционную исчисление (или алгебру).Нуу... Нет, создатели реляционной модели - с тобой не согласны. Они предлагают использовать D
Отличная локальная база. То что нужно!
А что такое "локальная база"?
Не ужели вам на вайти в айти смузи курсах не рассказывали?В зависимости от расположения программы, которая использует данные, и самих данных, а также от способа разделения данных между несколькими пользователями различают локальные и удаленные базы данных.
Данные локальной базы данных (файлы данных) локализованы, т. е. находятся на одном устройстве, в качестве которого может выступать диск компьютера или сетевой диск (диск другого компьютера, работающего в сети).
p.s "программы" - это то, что благодаря маркетолога, сейчас называют приложениями.
Локальность или нелокальность не имеет никакого значения. Тут дело не в локальности, а в принципиальном однопользовательском применении. Ничто не мешает приделать сокет, но от этого решение не станет многопользовательским.
Неплохой однопользовательский эрзац сиквела. Для остальных затей явно не то, что стоит выбирать.
И это не субд, а встраиваемый однопользовательский реляционный движок работы с данными. Наверное так, да?
Это помойка, которую легко заменяет ini-файл, ибо для других целей её не используют.
Не соглашусь. На реляционной "декларативке" зачастую куда проще данными оперировать. Во встройке какой-нибудь промышленной, например. Лайт же исконно использовали для упрощения интеграции БИУСов с автономными корабельными системами (чтоб и там и там была одна модель данных, ну или близкая).
Используют, и ещё как.
Одно из удобств - в локальности. Когда структура данных примитивная, но большие по числу строк и размеру данных объёмы - очень неплохо справляется, кстати.
Нет никакой "локальности". Куда ты Лайт встроишь не ограничено ничем, кроме полёта фантазии. Ещё раз, просто приделай сокет и не будет твое решение с Лайтом локальным, а вполне себе глобальным.
Я о другой локальности, ну да ладно.
Оверхед "сокета", когда тебе надо по одной строчке из пары миллионов выбирать - не шутка.
Если одну строку из миллионов? Никакого сколь-либо существенно влияния сокету тут не будет. Ты, наверное, имел в виду миллионы строк по одной? Да, тогда будет. Но Сиквел как раз про то, чтобы не выбирать миллионы по одной, а выбирать сразу множествами.
Не "одну", а по "одной". Множества там не особо катят.
Можно конечно хранимки написать, но блин, там база одноразовая - её ж ещё залить сначала придётся.