The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз БД SQLite 3.8.6

17.08.2014 23:20

Представлен релиз SQLite 3.8.6, легковесной базы данных, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Nokia, Bentle и Bloomberg.

В новом выпуске:

  • Добавлена возможность использования в запросах шестнадцатеричных чисел (формат 0x1234);
  • Увеличена производительность оператора "IN", что позволило до пяти раз ускорить выполнение некоторых запросов;
  • Внесённые оптимизации позволили на 25% снизить общую нагрузку на CPU по сравнению с выпуском 3.8.0, при тестировании в valgrind и test/speedtest1.c. При этом размер исполняемого файла увеличился по сравнению с выпуском 3.8.0 на 5%;
  • Устранена появившаяся в выпуске 3.8.2 ошибка в реализации "CREATE INDEX", которая при определённых обстоятельствах могла привести к созданию UNIQUE-индекса для столбцов, содержащих повторяющиеся данные.
  • В команду "PRAGMA integrity_check" добавлен код для выявления проблем с уникальностью в индексах UNIQUE и нарушений условия NOT NULL;
  • Добавлена SQL-функция likely;
  • Лимит SQLITE_MAX_ATTACHED увеличен с 62 до 125.


  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
  2. OpenNews: Релиз БД SQLite 3.8.5
  3. OpenNews: Релиз БД SQLite 3.8.0 с новым планировщиком запросов
  4. OpenNews: Новая версия БД SQLite 3.7.10
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40393-sqlite
Ключевые слова: sqlite
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (30) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:50, 18/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Nokia, Bentle и Bloomberg.

    Мне кажется, любая из этих компаний в одиночку могла оплатить всей команде разработчиков SQLite безбедную жизнь на протяжении нескольких поколений и при этом самой не обеднеть сколько-нибудь заметно.

    Ан нет - аж консорциум собрали, отдуваются.

     
     
  • 2.2, A.Stahl (ok), 01:19, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Ну справедливости ради надо отметить, что многие компании входят во множество различных "консорциумов" и поддерживают множество различных проектов. И пусть "консорциум" чем то, что Оракл сделал с MySQL. Так что пусть лучше всё остаётся так, как есть.
     
     
  • 3.12, adminsbk.ru (?), 12:50, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –6 +/
    ТО чо вы тут написали - похожая бред, гугл перевёл? промт.
     
     
  • 4.14, A.Stahl (ok), 12:58, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И пусть "консорциум" -> И лучше "консорциум"

    Настолько плохо знаешь язык, что любая опечатка делает текст непонятным? Бывает, вот только плохое знание языка это повод сидеть молча и "не отсвечивать" по языковым вопросам.

     
     
  • 5.22, irinat (ok), 17:47, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Всё решила запятая, которой нет.
     

  • 1.3, Бутират (?), 03:25, 18/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно записать в любое поле любой тип данных, независимо от того, какой тип этму полю был декларирован
     
     
  • 2.4, Аноним (-), 05:16, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно
    > записать в любое поле любой тип данных, независимо от того, какой
    > тип этму полю был декларирован

    Ну так там и данные все в одном виде хранятся - в текстовом. Считайте это "фишкой", всё-таки сфера применения у SQLite немного специфичная...

     
     
  • 3.5, Бутират (?), 05:57, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Ну так там и данные все в одном виде хранятся - в текстовом.

    Хранение данных - это уже несколько иной слой представления, к SQL отношения не имеющий.

    >> всё-таки сфера применения у SQLite немного специфичная...

    Сфера применения у SQLite обширнейшая. Часто это динамические языки. Где и так всё на расслабоне. И строгость в отношении хотя бы к хранилищу данных была бы очень к месту.

     
     
  • 4.6, Zontus (?), 07:02, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> всё-таки сфера применения у SQLite немного специфичная...
    >>Сфера применения у SQLite обширнейшая. Часто это динамические языки. Где и так всё на расслабоне. И строгость в отношении хотя бы к хранилищу данных была бы очень к месту.

    С кривыми руками выбирай другую ДБ. Хотя кривые руки обычно от кривых мозгов

     
     
  • 5.7, Бутират (?), 07:24, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    От кривых рук никто не застрахован - человеческий фактор.  Если я запишу строку в поле объявленное как числовое - значит скорее всего я допустил ошибку. Компьютер должен предотвращать потенциальные человеческие ошибки, а не поощрять. Лучше уж комптютер пусть проверяет чем мне по пол часа вручную отлавливать баг.
     
     
  • 6.30, vlivyur (ok), 12:06, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так и заставьте компьютер проверять попытку записи букв в поля для этого не предназначенные.Все проверки на клиенте-до записи в БД
     
  • 2.8, anonymous (??), 09:14, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А strict-mode так и запилили? Последний раз когда пробовал SQLite было возможно
    > записать в любое поле любой тип данных, независимо от того, какой
    > тип этму полю был декларирован

    Все типы представлены для совместимости с другими БД и имеющимися схемами.
    Внутри sqlite тип один.

     
     
  • 3.10, Бутират (?), 09:51, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не вижу причин цитировать здесь документацию sqlite. У mysql так вообще 8 разных движков хранения данных. Пусть хоть в json хранит - какая разница. Важно что отсутствуют проверки типов при чтении/pfgbcb. Что в сильно усложняет поиск ошибок при разработке.
     
     
  • 4.11, pkdr (ok), 11:36, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вообще-то sqlite - позиционируется именно как простейшая и легковесная БД, где многие вещи, типичные для "больших" БД просто выкинуты для обеспечения этих простоты и легковесности.
    Если вам нужны такие проверки, возможно вам стоит смотреть на более "продвинутые" БД - postgresql/mysql/mariadb/etc...
     
     
  • 5.13, Бутират (?), 12:55, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> как простейшая и легковесная БД, где многие вещи, типичные для "больших" БД просто выкинуты для обеспечения этих простоты и легковесности

    Ну прям определение всех новоиспеченный nosql key-value помоек. Значит и sqlite можно причислить к ним же

     
     
  • 6.17, имя (?), 14:33, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ник у тебя подходящий для такого комментария.
     
     
  • 7.18, Бутират (?), 14:51, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А чем не nosql-помойка. Куда угодно записывай что угодно. Оно проглотит и даже ворнингом не поперхнется
     
     
  • 8.24, Zontus (?), 20:32, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда все собеседники намекают на кривые руки, это повод задуматься, Дубират ... текст свёрнут, показать
     
     
  • 9.25, Бутират (?), 02:09, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Собеседники со второго сообщения начали на личности переходить Словно я не sqli... текст свёрнут, показать
     
  • 3.28, angra (ok), 04:09, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Внутри sqlite тип один.

    Вообще-то нет. Для примера "The INTEGER storage class, for example, includes 6 different integer datatypes of different lengths. This makes a difference on disk."
    Другое дело, что тип связан с самим значением(ячейкой), а не с полем(колонкой, столбцом).

     
  • 2.26, angra (ok), 03:50, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А мне наоборот эта особенность sqlite очень нравится.Если отсутствие типа не влияет на скорость работы и потребляемое место, то к черту эти тупые ограничения. Работать в этом плане с sqlite после традиционных sql одно удовольствие.
     

  • 1.9, хрюкотающий зелюк (?), 09:18, 18/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    likely разве не было?
     
  • 1.15, streletsky (?), 13:41, 18/08/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    интересно когда они починят upper для не английских букв
     
     
  • 2.16, Аноним (-), 14:13, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    кодировка? не, не слышал.
     
     
  • 3.23, streletsky (?), 20:03, 18/08/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в том то всё и дело что поддержка ASCII символов без кириллицы,
    но я вообще использую UTF-8, а проблему пока решаю добавлением в таблицу такого же поля со значением в upper-е
     
     
  • 4.27, angra (ok), 04:03, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов без кириллицы" само по себе глупость.

    Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого sqlite, было бы глупо их включать. При этом sqlite позволяет добавлять и использовать в запросах пользовательские функции, так что ничто не мешает добавить свою версию преобразования. Хотя с такими знаниями ты вряд ли это осилишь.


     
     
  • 5.29, streletsky (?), 11:44, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в
    > однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов
    > без кириллицы" само по себе глупость.

    ну извини, запятую забыл… "ASCII символов, без кириллицы"
    сразу доказывать, что самый умный стал - молодец!


    > Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого
    > sqlite, было бы глупо их включать.

    конечно, глупее некуда …

    >При этом sqlite позволяет добавлять
    > и использовать в запросах пользовательские функции, так что ничто не мешает
    > добавить свою версию преобразования.

    конечно ни кто не мешает, но писать udf как-то не хочется, тем более под андроид
    > Хотя с такими знаниями ты вряд ли  это осилишь.

    тут ты возможно прав, знания нужно усилить…

     
  • 5.31, Anonym2 (?), 13:56, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Для безграмотных сообщаю, кириллица(да и вообще все символы выше первых 128 в
    > однобайтных кодировках) не входит в ASCII. Так что выражение "ASCII символов
    > без кириллицы" само по себе глупость.
    > Размер таблиц преобразований для всевозможных encoding и их collations больше размера самого
    > sqlite, было бы глупо их включать. При этом sqlite позволяет добавлять
    > и использовать в запросах пользовательские функции, так что ничто не мешает
    > добавить свою версию преобразования. Хотя с такими знаниями ты вряд ли
    > это осилишь.

    Они в стандартной библиотеке...

     
     
  • 6.32, streletsky (?), 15:33, 19/08/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    действительно все решается через стандартную icu
    http://www.sqlite.org/faq.html#q18
     
  • 2.33, бедный буратино (ok), 06:01, 21/08/2014 [^] [^^] [^^^] [ответить]  
  • +/
    1. собери с icu

    или

    2. через внешнюю функцию

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру