Состоялся (http://permalink.gmane.org/gmane.comp.db.sqlite.announce/53) релиз SQLite 3.10.0 (http://sqlite.org/), легковесной базы данных, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.
Основные новшества (http://sqlite.org/releaselog/3_10_0.html):
- Обеспечена возможность использования операторов LIKE (http://sqlite.org/lang_expr.html#like), GLOB (http://sqlite.org/lang_expr.html#glob) и REGEXP (http://sqlite.org/lang_expr.html#regexp) с виртуальными таблицами (http://sqlite.org/vtab.html);
- В утилиту sqldiff (http://sqlite.org/sqldiff.html) добавлена опция "--transaction";
- Реализованы новые интерфейсы sqlite3_db_cacheflush() (http://sqlite.org/c3ref/db_cacheflush.html) и sqlite3_strlike() (http://sqlite.org/c3ref/strlike.html);
- При открытии символической ссылки на БД, обеспечивающие журналирование файлы теперь создаются в привязке к реальному имени файла, а не имени символической ссылки;
- При использовании ввода/вывода с применением отображения в память (memory-mapped I/O (http://sqlite.org/mmap.html)), отображение теперь производится в режиме только на чтение, что не даёт возможности случайно изменить БД в случае переполнения буфера в приложении или проблем с указателями;
- В расширение для работы с форматом JSON добавлены новые SQL-функции json_group_array() (http://sqlite.org/json1.html#jgrouparray) и json_group_object() (http://sqlite.org/json1.html#jgroupobject);
- Добавлена сборочная опция SQLITE_LIKE_DOESNT_MATCH_BLOBS (http://sqlite.org/compile.html#like_doesnt_match_blobs);
- Внесены оптимизации производительности, ускорившие работу с БД на 2-3%;
- В интерфейс командной строки (http://sqlite.org/cli.html#dotcmd) добавлены новые команды ".changes ON|OFF" и ".vfsinfo".
URL: http://permalink.gmane.org/gmane.comp.db.sqlite.announce/53
Новость: http://www.opennet.me/opennews/art.shtml?num=43634
Лучшая БД. Только её и использую.
Хотел ответить, но увидел ник и решил наморозить чушни.
Не Аноним, значит не торт.
А сортировку по кирилице так и не научился...
Где full join суки
left join
union all
right join
union all? :) Все согласны? :)
Вообще, ни разу не сталкивался на реальной БД (в которой таблицы построены в соответствии с нормальными формами) с ситуацией, когда нужно использовать full join. Кто может привести пример? :)
А разве там "=" нет? (т.е. оно самое)
Достаточно редко используемая вещь. К тому же вполне себе чере union решается.
А вот хранимые процедуры было бы реально круто.
> Код SQLite распространяется как общественное достояние (public domain)Хм, а не тот ли это софт, на котором написано "The Software shall be used for Good, not Evil"? Наверное, я что-то путаю.
Нет, то был jslint или что-то типа того
> Нет, то был jslint или что-то типа тогоА, да-да-да! Спасибо.
Отчего opennet никогда не упоминает H2? О ней вообще почему-то мало кто знает, хотя скорость её работы превосходная, регулярно выходят обновления.
> Отчего opennet никогда не упоминает H2? О ней вообще почему-то мало кто
> знает, хотя скорость её работы превосходная, регулярно выходят обновления.Ну так напиши новость про какой-нибудь релиз. Да и линк мог быть дать здесь сразу.
Оттого что она до сих пор кривая и сырая? разваливается на ура, а полечить невозможно, плюс возможность потери данных из-за проблем с ACID проталкиваемая как "фича за скорость", что в купе делает её ненужной для задач отличных от студенческих поделок на коленке.
Оттого что среди баз держащих всё in memory она на удивление тормозная?
Оттого что кроме джавы с ней вообще ничего нормально не работает?
Ну и по ресурсам среди встраиваемых она куда прожорливее чем SQLite, Berkeley DB и даже FireBird
Не правда! Оно даже с Джавой плохо работает.
Так что же тогда в джава использовать?
>что же тогда в джава использовать?Java DB?
вопрос конечно холиварный на зачем нужен встраиваемый SQL неужели какому нибудь видеоплееру нужно связывать таблицы, использовать транзакции и тд? Мне кажется для полного ФГМ не хватает триггеров и хранимых процедур( ну вас![сообщение отредактировано модератором]
видимо для того чтобы жрать батарею
Задай этот вопрос гениям, работавшим над KDE PIM, которым не хватило sqlite для адресной книги, понадобился полноценный мускул.
Плееру, который просто проигрывает один файл, БД конечно без надобности, но среди плееров ведь есть не только mpg123 или mplayer, но и монстры типа amarok или itunes, у которых собственно проигрывание лишь малая часть функционала, а media library отлично ложится на реляционную модель БД.
Ну и наконец кроме плееров существует очень много разного софта, в том числе нуждающегося в SQL, транзакциях и триггерах(кстати, в sqlite они есть), но при этом не требующего высокой concurency, то бишь не нуждающегося в отдельном сервере БД.
сейчас у любого ЯП есть стандартные стредства работы с XML/JSON, неужели эти два ЯР такие бедные, что нимогут удовлетворить ваши потребности? и про amarok такого тормозящего и жирного поделия я еще не встречал(
и да проект KDE с 4-ой версии стал совсем неадекватен(
подумав, понимаю что вы правы имхо ФГМ ни имеет границ, поэтому лучше встроенный SQL чем MySQL/PostgreSQL в моем телефоне)
Можно еще Oracle или Linter впихнуть и назвать Military Edition [$devicename].
> Задай этот вопрос гениям, работавшим над KDE PIM, которым не хватило sqlite для адресной книги, понадобился полноценный мускул.
pkg info akonadi
...
Comment : Storage server for KDE-Pim
Options :
MYSQL : off
PGSQL : off
SQLITE : on
ЧЯДНТ?
Посмотрите список софта
aptitude search "?depends("sqlite")"
И задайте себе вопрос - может быть разработчикам, пишущим далеко не первый год сотни используемых ежедневно приложений, виднее, и это не они епнулись изобретать велосипеды на всяких кривых XML'ах, сжирающих для тех же задач вчетверо больше ресурсов?
круто! xml велосипед? сейчас почти все форматы, ну кроме растра в xml, ну да они велосипедостроители, а SQLite божественен особенно если учитывать что некоторые структуры данных не опишешь таблицами рсубд, но вы же гений, куда мне до вас( позвольте простой вопрос как проще описать например плейлист в виде xml или таблиц, если песня обьект и у нее много атрибутов?
Не скажу, что XML не нужен вообще, но вы сейчас явно неудачный пример притянули за уши. И когда для народа проблема сделать пару таблиц (песни и их атрибуты, связь один ко многим в простейшем случае, по которым, кстати, удобно и быстро делается поиск на SQL), то появляются велосипеДИЩИ, которые используют XML во все щели где не надо. Я уже молчу про то, что XML - решето by design.
Опять же скорость и занимаемые объёмы.
Как вы, залечите XML-файл на 10000 записей, если он был повреждён, например, из-за отключения света в момент записи?
Ну и посмотрите на ту же мозиллу хотя бы. Ну не такие ж лохи, как я, там работают, но тем не менее sqlite там активно пользуется.
А и можно подробнее про "почти все форматы"? А то как ни возьму что-то мало мальски серьёзное, там свои бинарные форматы, даже всякие веб-апи и то уходят в JSON и protobuf
форматы на базе XML: XSPF - плейлист, RSS - лента новостей, OPML - архив лент новостей, ODF/OOXML - офисные документы, SVG - векторная графика, ORA - формат для обмена растровых редакторов, HTML - да-да то самый и еще докуя, если тебе интересно почти все стандарты W3C, IETF и OASIS которые конечно относятся к XML а их там over9000) есть еще текстовые форматы vCard и iCal и еще вагон других текстовых форматов, к чему тут текстовые форматы? да к тому что и XML текстовый формат и я сравниваю текстовые форматы против реляционной куйни для конфигов! и если ты так привык к табличкам используй CSV(парсер займет максимум 20 строк кода) И если это тебя не убедило что не под каждый пук нужно юзать SQL, ну тогда мне тебя жаль, ты сказал только один минус XML мол много жрет так как текстовый и типа сложный очень, а форматы твоего SQLite тоже внезапно текстовые и SQLite их парсит и никакой гиперскоростной бинарщиной здесь и не пахнет, а еще XML дружит с UTF8 да и вообще он заебс)
и плиз не сравнивай форматы передачи данных (protobuf) с форматами хранения конфигов( и плиз что уж у тебя такое серьезное что юзает бинарщину? все серьезное уже как лет 10 на XML с вкраплениями JSON и ORM/SQL сидит)
>> с форматами хранения конфиговО, вот и проболтался - вот это единственное нормальное применение (и то не всегда!) для XML, помимо всякой вебовщины (которая зародилась до XML, из SGML, так что не надо тут притягивать за уши XML). А дальше узнаём, что это близкое к XML поделие имеет уйму ограничений by design, не позволяющих сделать нормальный интерактивный сайт на голом HTML. И да, HTML появился гораздо раньше XML, зря вы его за уши притянули, не удачный пример.
XSPF - мифический зверь. На своей 15-летней файлопомойке не нашёл ни одного файла с этим расширением.
OPML - не архив лент (архив ленты в моём понимании - это все записи, которые лежали в новостной ленте), а тупо список, считайте плейлист, этих самых лент. ОЧЕНЬ ПРОДАКШЕНОВЫЙ ФОРМАТ! Юзается всеми чаще чем PSD и DWG вместе взятые.
ODF? Ну фиг его знает. Оно до сих пор так клёво поддерживается, что у меня все документы или в odt или в doc, а они бинарные. И либра выбирает по умолчанию odt, не odf. Про OOXML та же фигня. Почему?
Ваши парсеры CSV за 20 сек потом радостно разваливаются на кавычках, спецсимволах и многострочных вставках, видали таких шустрых, да, потом такие медленные как я переписывают такой клёвый код, чтобы оно хотя бы работало. На эту тему у меня давно своё написано, под свои нужды, и используется там, где уместно, а не "везде где фанатизьм прёть".
А покажите, в каком месте формат SQLite текстовый? Или вы там нечаянно увидели, что название колонок в таблицах и вставленные данные легли "как есть" и радостно забили на всю бинарную начинку? Тогда и MySQL/Postgre/Oracle текстовые с таким же успехом, только это бред.
Если поливание говном и невозможность объективной оценки актуального положения вещей в мире ПО ваша фича, то что с вами обсуждать. Вы даже гуглить не научились же
Чувак, вот все ты правильно говоришь... И про тормозной xml, и про реляционные связи (не зря оно называется реляционная СУБД), и, самое главное, про сферы применения... Одно зря - "ODF? Ну фиг его знает. Оно до сих пор так клёво поддерживается, что у меня все документы или в odt или в doc, а они бинарные. И либра выбирает по умолчанию odt, не odf. Про OOXML та же фигня. Почему?" Вот прям все впечатление испортил.
ODF - стандарт "файл открытого документа", который говорит, что документ должен состоять из некоторой файловой иерархии, где лежат XMLки, запакованный zip-ом.
ODT - ПОДВИД ODF, описание текстового документа как разновидности ODF. То же с ODS - табличный ODF.
Т.е.:
1. ODF <- ODT (ты, как сторонних реляционной теории, должен понять)
2. ODT НЕ бинарный.
Ввиду обобщенности ODF либра и не может выбрать его по умолчанию. В общем виде ODF - абстрактен и является шаблоном для ODT, ODS и остальных видов документов.
И, собственно, для хранения документов XML-форматы не так уж плохи. Сама идея (не скажу за упоротую реализацию что в ODF, что в OoXML) таки неплоха. Подумай о необходимости парсинга и генерации этих данных. Таки XML-ку руками без специфических драйверов собрать/разобрать проще. Впрочем, признаю, про сферы применения ты писал, и вопрос, скорее, именно в применимости.
Каюсь, тут дал маху, не перепроверил, просто на шару помнил что если в него тыкнуться текстовым редактором, то открывается бинарь, упустил что оно жато.
И да, как и для веба, здесь допустим Markup Language.
Позор моим сединам =)
ты спросил какие форматы есть основанные на xml я тебе ответил, ты не говорил чтобы я тебе написал только те которые используются в продакшене( и да насчет CSV если он для вас настолько сложен, то проще формата нет( честно мне пофиг в каком формате хранятся SQLite таблицы для меня важно то что они используются не по назначению, SQLite классная технология, но не такая универсальная как вы хотите ее нам представить...
Не не не, не отмазывайтесь, вы сказали, что XML-формат вперде планеты всей и торчит везде и каждый день без него плачут маленькие негритята, а тут выясняется, что для серьёзных задач он как-то не удел.
Кто вам сказал, что CSV сложен для меня?
А какой я хочу вам её предствавить? Вы тут начали сами себе противоречить. Изначально вы писали что встраиваемый SQL ненужен, а тут вдруг "технология классная". А по какому назначению её использовать?
я не говорил только про XML, я говорил что любой текстовый формат для конфигов более адекватен SQLite. Обьяснить для чего нужно SQLite? Обьясняю) SQLite используется когда у вас есть множество таблиц логически связанных между собой, и чтобы это логическая связь не была лишь плодом вашего вооображения используются РСУБД. Если же вам нужно описать обьекты используйте XML/JSON или другой, если вам нужна просто таблица используйте CSV. И еще раз напоминаю, что SQLite это отличный инстумент для своей сферы применения, я лишь критикую его использование в качестве формата хранения конфигов! Если бы Кодд узнал, что РСУБД будут использовать в качестве инструмента хранения конфигов он бы в гробу перевернулся(
Вообще-то про КОНФИГИ изначально ты сам выдумал и за уши притянул. Перечитай уже свой первый пост
перечитал и что? я сразу сказал что практика использования SQLite в приложениях для хранения их конфигов не выдерживает критики. Аааа!!! вот вы о чем! конфиги это не только параметры запуска процесса, но и например плейлист, лента новостей тоже вспомогательные файлы, их обычно не выделяют в другую категорию и тоже зовут конфиги)
Ууу, как грозно... очередной софт, написанный на коленке, который валится с OOM при попытке обработать весь список песенок мало мальски старого меломана? Ну всё, сдаюсь =)
XML виноват что софт написан на коленке? Пишите за партой может падать не будет.
Aliorum medicus, ipse ulceribus scates.
SOAP смотрит как-то недовольно, свирепо и в то же время грустно и с недоумением
> круто! xml велосипед? сейчас почти все форматы, ну кроме растра в xml,
> ну да они велосипедостроители, а SQLite божественен особенно если учитывать что
> некоторые структуры данных не опишешь таблицами рсубд, но вы же гений,
> куда мне до вас( позвольте простой вопрос как проще описать например
> плейлист в виде xml или таблиц, если песня обьект и у
> нее много атрибутов?Дерево тоже не на все случаи жизни. Универсален только граф.
это утопия)
> ФГМ не хватает триггеров и хранимых процедур( вы епнулись ну вас!Я вас слегка разочарую. Триггеры есть.
я не удивлен, ФГМ как я уже выразился не знает границ( жду появления OLAP и их языков типа MDX, полноценного DataMining с встраиванием R, так как данные без визуализации не кошерно как то и вообще пусть делают что хотят!( я пошел спать! и да генерацию отчетов с экпортом в HTML/PDF не забудьте деспоты!
<?xml version="1.0" encoding="utf-8"?>
<имяГосподина>Черный Властелин</имяГосподина>
<егоРабы>
<раб порядковыйНомер="666">
<имя>Кончита</имя>
<фамилия>Вурст</фамилия>
<пол>Женщина с бородой</пол>
<какПопалВРабство>
<причинаИСледствие>запил на бритву</причинаИСледствие>
<причинаИСледствие>отрастил сиськи</причинаИСледствие>
<причинаИСледствие>спел на евровиденье</причинаИСледствие>
<причинаИСледствие>чем привлек внимание Черного Властелина</причинаИСледствие>
</какПопалВРабство>
</раб>
</егоРабы>Попробуйте на SQLite такое сделать неудачники) и да XML развивает креативность и что главное не привлекает внимание... ну вы поняли кого) ХА-ХА-ХА!
Легко ложится в БД, да, придётся делать аж не одну таблицу, от чего у кого-то видимо дико бомбит.
Легко ложится в JSON почти как есть, который поддерживается SQLite, после чего работать с ним становится легко и комфортно.
Так какую креативность оно развивает? Я вижу, с такими наклонностями (в экземплах), вы привлекаете много внимания дядек в белых халатах, не бойтесь их, будет просто "чик" как комарик и вас перестанет беспокоить злой и страшный SQLite
JSON это по сути облегченный XML) ну и логика у вас сударь использовать SQLite чтобы в нем использовать JSON вот это я понимаю оверхед! почему бы не юзать JSON напрямую или религия не позволяет?
JSON появился почти в одно время с XML и отпочковался от JavaScript, он более лаконичный, легко читается, у него нет явных дыр типа этой http://habrahabr.ru/post/170333/ , скорость сериализации выше, его легче расширять.
Если там мало записей, то конечный пользователь не увидит разницы по перфомансу/ресурсам.
А вот если сущность не одна, а 1000000, то это совсем не оверхед. Тем более, если мне надо обрабатывать не все из них, а только какие-то конкретные. А вот держать в этой ситуации все 1000000 в памяти, чтобы вручную перелопатить их ища нужные - вот это знатный оверхед.
да вы лжец или мы живем в параллельных вселенных! XML 1.0 опубликован W3C в 1998 году, JSON опубликован в октябре 2013 ECMA как стандарт ECMA-404. Я думаю стандарты это более четкое определение чем ваше отпочковался... И если говорить кто был первым из этих двух то это был дедушка SGML на базе которого создан XML)
2013-ый? А точно из нас двоих я лжец?
как стандарт да 2013, вот пруф http://www.ecma-international.org/publications/files/ECMA-ST...
Из вашего же дока.
JSON was inspired by the object literals of JavaScript aka ECMAScript as defined in the ECMAScript Language Specification, third Edition
который 1999 год. В коем виде и поддерживается всем софтом без исключения. А в 2013 и 2014 годах были лишь правки. Вы бы сами почитали?
глянь на титулке! как СТАНДАРТ в 2013! а если будем говорить о первом упоминании то что уж то XML "отпочковался" от SGML который датирован 1986 годом и судя по вашей логике XML первое коственное упоминание о XML было 30 лет назад.
С той лишь разницей, что в 86-ом году про XML не было ни единого упоминания, а в 99-ом про JSON было вполне конкретно написано. А так же что в вашей доке написано, что она перекрывает более ранние описания JSON. Вы прочтёте её или где? Мне надоело спорить с человеком, не осилившим то, что сам проталкивает
на минуточку XML это упрощенный SGML и полностью с ним совместимый, так что разве не было упоминания имени XML, а синтаксис SGML/XML был известен уже тогда и с того времени не изменился. Но видимо вы не видите разницы между стандартом и ранними версиями( не хотите не спорьте
вы меня окончательно осадили( помнится мне такая проблема есть только у XML с его DOM API, но позвольте есть SAX API/XPath которые не содержат все 1000000 сущностей в памяти. Так что ваши доводы про жручесть XML не более чем миф.
XPath. Да. Клёвая штука. Только ей в более-менее сложных вариантах придётся перелопатить весь док, чтобы найти все совпадения, а индексами там нифига не пахнет, да. А ещё за счёт размеров у БД больше шансов влезть в ОЗУ (или хотя бы индексы туда всунуть), чем затянуть какой-нибудь XML на пару-тройку Гб.
а зачем для конфига индексы? лол
мы просто говорим о разном) я вам говорю что КОНФИГИ лучше хранить в текстовых файлах, как вариант в XML/JSON, а вы мне говорите что плохо хранить БД в XML, ну это же очевидно. SQLite для БД, текстовые форматы для конфигов)
см. http://www.opennet.me/openforum/vsluhforumID3/106247.html#70
Вы сами с собой там о чём-то говорите, выдумываете какие-то темы на ходу. Мы тут при чём?
если исходить из вашей логики, то вы лишь плод моего воображения
Так и есть
> XML развивает креативностьт.е. бардак.
XML используют для обменов данными и для промежуточного хранения данных.
А там где нужна скорость доступа используется БД.
Надо уметь подбирать инструменты под требования задачи.
и я об этом, но хранить конфиги в соответсвии с реляционной моделью в десятках таблицах( это перебор
Зато они читаются из XML геморойно и долговато.
Текстовый фал типа:
раздел.подраздел.подподраздел = значение;
Гораздо менее геморойно обрабатывать.
К примеру QtCreator походу в XML конфиги хранит оттого и грузится как улитка.
плюсую)
геморойно и долговато - эта та цена которую платит XML за свою мощь. Хотя и это тоже кащунство ведь XPath работает ой как шустро, да и я не видел конфиги в десятки тысяч записей от которых комп бы ревел и плакал)
> К примеру QtCreator походу в XML конфиги хранитБольшая часть в стандартном для QSettings ini
> оттого и грузится как улитка.
1-2 секунды - это "улитка"? интересно что вы запоёте когда IntelliJ запустите
> Попробуйте на SQLite такое сделать неудачники) и да XML развивает креативность и
> что главное не привлекает внимание... ну вы поняли кого) ХА-ХА-ХА!ТАКОЕ, конечно, не получится. Хотя бы потому что валидация схемы будет на этапе создания таблиц. Т.е. невалидную структуру SQLite не схавает. А ты умудрился запилить хрень, на которой каждый второй парсер упадет, а остальные скажут "чувак, мы эту хрень за XML не признаем", и радуешься.
> и да XML развивает креативность иСо своей креативностью идите в... свои домашние проекты с мегаобъемами данных до тысячи записей.
>> и да XML развивает креативность и
> Со своей креативностью идите в... свои домашние проекты с мегаобъемами данных до
> тысячи записей.Кстати, изучение МАТЕМАТИКИ эту самую креативность снижает. Так что "развитие креативности" лично для меня - вовсе не преимущество, а как бы наоборот. Типа способность потребовать провести 7 перпендикулярных красных линий (некоторые из которых не красные) в одной плоскости.
Супергерой ZIP спешит на помощь!
> Супергерой ZIP спешит на помощь!после xz ваш супергерой давно на пенсии