The OpenNET Project / Index page

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

Релиз СУБД SQLite 3.25 с поддержкой оконных функций

16.09.2018 10:11

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

Основные изменения:

  • Добавлена поддержка оконных функций (window-функции или аналитические функции), позволяющих для каждой строки запроса выполнить вычисления, используя другие строки. В отличие от агрегатных функций, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят агрегирование на основе содержимого "окна", включающего одну или более строк из результирующего набора;
  • Добавлена поддержка переименования столбцов при помощи команды "ALTER TABLE table RENAME COLUMN oldname TO newname";
  • При переименовании таблиц через "ALTER TABLE" реализовано автоматическое обновление всех ссылок на новое имя в триггерах и представлениях;
  • В состав включён новый модуль Geopoly с реализацией альтернативного интерфейса к R-Tree, использующего для обмена данными формат GeoJSON;
  • Внесены улучшения в оптимизатор запросов: Исключены излишние чтения столбцов в агрегатных запросах, если эти столбцы не упоминаются в агрегатных функциях и не используются в выражении "GROUP BY". Добавлена оптимизация "N-early-out", помогающая ускорить выполнение операции "IN" при наличии индексов, охватывающих несколько столбцов. Обеспечено раскрытие присвоения констант в блоке WHERE (например, "a=99 AND b=a" будет преобразовано в "a=99 AND b=99");
  • В VFS для UNIX-систем для каждой inode теперь применяется отдельный мьютекс, вместо общей совместной блокировки для всех inode. Изменение позволяет поднять производительность при использовании SQLite в многопоточных программах;
  • В "PRAGMA integrity_check" улучшено выявление проблем, связанных с порчей списка свободных страниц в хранилище;
  • Для индикации бесконечных значений команда ".dump" теперь использует число 1e999;
  • Устранена ошибка, которая при редком стечении обстоятельств могла привести к бесконечному зацикливанию в движке генерации байткода при выполнении оптимизации конструкции "ORDER BY LIMIT".


  1. Главная ссылка к новости (https://www.mail-archive.com/s...)
  2. OpenNews: В рамках проекта LiteTree развивается вариант SQLite с поддержкой ветвления БД
  3. OpenNews: Релиз СУБД SQLite 3.24
  4. OpenNews: Релиз СУБД SQLite 3.21
  5. OpenNews: Релиз СУБД SQLite 3.20.0
  6. OpenNews: Релиз СУБД SQLite 3.19.0
Лицензия: CC-BY
Тип: Программы
Ключевые слова: sqlite
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (83) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, timur.davletshin (ok), 10:20, 16/09/2018 [ответить] [показать ветку] [····]    [к модератору]
  • –11 +/
    Эх, всё бы было классно с этой sqlite, если бы она тормозить не начинала из-за фрагментации через какое-то время активного использования. А то VACUUM+REINDEX ломает запускать регулярно. На десктопе ещё ладно, это можно сделать, но они же его и на мобильные устройства запихивает во все места. Что с одной стороны оправдано, а с другой затрудняет обслуживание.
     
     
  • 2.2, Аноним (2), 10:48, 16/09/2018 [^] [ответить]    [к модератору]
  • +1 +/
    На мобильных устройствах в основном флэш, им фрагментация фиолетова.
     
     
  • 3.6, timur.davletshin (ok), 11:09, 16/09/2018 [^] [ответить]    [к модератору]
  • –7 +/
    И пухнущая DB c кучей  dead tuples тоже им фиолетова. Мне кажется, что такие люди, как ты, в этих случаях бегут покупать новый телефон, т.к. старый "после обновления вообще тупить стал". Зацепись в режиме разработчика через adb shell и посмотри на это позорище до VACUUM+REINDEX и после.
     
     
  • 4.16, пох (?), 11:26, 16/09/2018 [^] [ответить]    [к модератору]
  • –3 +/
    > И пухнущая DB c кучей  dead tuples тоже им фиолетова.

    тоже.

    во всяком случае, пока "куча" не превышает разумных размеров. Что будет, если пихать в нее картинки по 20 мегапикселей - я, правда, не знаю, у меня есть вполне себе нормальная lightroom, я не нуждаюсь в пионерских подделках.

     
     
  • 5.17, timur.davletshin (ok), 11:30, 16/09/2018 [^] [ответить]    [к модератору]
  • –6 +/
    Ой да ладно, LR не тормозит у него. Басни тоже мне рассказываешь. Оно уже OpenCL научилось или всё продолжает камень насиловать?
     
     
  • 6.20, пох (?), 11:41, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    не знаю, у меня нет поддержки opencl на той системе, где я вожусь с lr.
    при ее workflow все основное торможение происходит, когда все кнопки уже нажаты и я ушел от клавиатуры.

     
     
  • 7.21, timur.davletshin (ok), 11:46, 16/09/2018 [^] [ответить]    [к модератору]  
  • –4 +/
    Я вам искренне сочувствую, т.к. работать без ускорения на GPU — тратить в ~5 раз больше времени (лично у меня) на генерацию preview и экспорт файлов. А на современных камерах с 24+ MPx это вообще становится адом.
     
     
  • 8.23, пох (?), 12:20, 16/09/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    машина - она железная. Флэшку засовываешь, идешь обедать - оно копируется и генерит свои превьюшки. export делается батчем, и идешь спать. Утром, наверное, сгенерит - но проверять мы это не будем, пора на работу.

    а если надо долго возиться с конкретным снимком - все равно понадобится фотошоп. Который тормозит много где, и никакое gpu ему радикально не помогает - какие-то операции будут побыстрее, каким-то не поможет.

    чтобы стало заметно быстрее - надо менять все железо по кругу, не только видео, ставить распоследние версии всего (которые уже не продаются а даются на время подержать двумя пальчкиками)... в общем, не будучи в этом профессионалом, не вижу смысла заморачиваться.

     
     
  • 9.28, timur.davletshin (ok), 12:38, 16/09/2018 [^] [ответить]    [к модератору]  
  • –5 +/
    Вы реально считаете, что для такого workflow нужен LR? Я бы рекомендовал вам открыть для себя всё-таки мощь GPU — на электричестве сэкономите, да и жужик, молотящий на всю слушать не особо приятно.
     
     
  • 10.36, пох (?), 15:46, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    да. он только под такой и заточен.
    это средство массовой обработки по шаблону, а не детальной возни с каждым снимком.

     
     
  • 11.38, timur.davletshin (ok), 16:06, 16/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    > да. он только под такой и заточен.
    > это средство массовой обработки по шаблону, а не детальной возни с каждым
    > снимком.

    ORLY?! То-то я смотрю интернеты пестрят мануалами по детальной возне с со всеми этими движочками и по художественной обработке.

     
     
  • 12.39, пох (?), 16:25, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    де6илов - которым еще и нужны "мануалы в интернетах", ибо нормальную литературу осилить они не могут  - полно.

    движки эти выставляют обычно один раз под серию снимков в примерно одинаковом свете - очень часто это вообще все, что делается в самом LR. Оно именно на такой подход и рассчитано.

    если кому-то понадобилось сначала купить(недешево) профессиональный инструмент, а потом забивать им гвозди - адоба не возражает, продаваны cuda-capable видеокарт тоже. Кто-то этим лохам еще и, вот, инструкцию по удобному держанию микроскопа для забивания гвоздя продает.

     
     
  • 13.43, timur.davletshin (ok), 17:08, 16/09/2018 [^] [ответить]     [к модератору]  
  • –3 +/
    Нормальная литература для таких инструментов быстро теряет актуальность, т к от... текст скрыт, показать
     
     
  • 14.53, пох (?), 19:49, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > Нормальная литература для таких инструментов быстро теряет актуальность

    нормальная литература для таких инструментов написана хрен знает когда. Ничего с тех пор в фотографии глобально не изменилось, отдельные мелочи, мало влияющие на результат. Тем более что LR старательно воспроизводит работу с фотоматериалами, про которую книги написали еще в прошлом веке.

    > Касательно иронии на предмет GPU: я так понял, что производительность тебя не интересует.

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

     
     
  • 15.54, timur.davletshin (ok), 20:06, 16/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    У меня складывается впечатление, что вам встроенного в камеру преобразования raw в JPG за глаза хватит, там тоже можно яркость/HDR/дисторсию править и пакетом всё преобразовывать. И, что самоё главное, там за секунды это делается.

    "Lr старательно воспроизводит работу с фотоматериалами?" — да ладно, там уже есть профили "под плёнки Konica, AGFA" и прочее? У меня всё больше складывается мнение, что вы им плоховато владеете.

     
     
  • 16.59, пох (?), 21:35, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    у меня сложилось впечатление, что в фотографии вы полнейший дилетант.
    поэтому не вижу смысла тратить на вас время.

     
     
  • 17.62, timur.davletshin (ok), 22:06, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Ну пока что больше информации для выводов предоставил ты, а не я.
     
     
  • 18.71, x3who (?), 00:27, 19/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    >  Ну пока что больше информации для выводов предоставил ты, а не я.

    Ошибаетесь - в принципе очевидно, что вы не заморачивались обработкой фоточек.

    Я только не понял зачем ваш оппонент использует какой-то лайтрум, когда есть нормальный rawtherapee.

     
     
  • 19.72, timur.davletshin (ok), 05:36, 19/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    А в rawtherapee уже завезли маски и кисти, там можно хотя бы пятна на объективе/сенсоре убрать? Ну, специалист по фоточкам, ответишь? Я уже не говорю о его интерфейсе и отсутствии аппаратного ускорения и однопоточность многих модулей. Нет, я не говорю, что он плох, там есть ряд очень качественных с точки зрения качества кода модулей (поэтому их и юзают в сторонних проектах), но есть и ряд серьёзных просчётов.
     
  • 19.73, пох (?), 11:02, 19/09/2018 [^] [ответить]    [к модератору]  
  • +/
    дык, то же ж самое - rawtherapee, даже если абстрагироваться от ее болезней связанных с не самым лучшим парсингом собственно равов и не самыми хорошими алгоритмами поверх него - не очень удобна, когда надо разобрать пять сотен фоток из очередной поездки в теплые края - предположим даже, я буду использовать что-нибудь типа frv для удаления "снимок сделан при закрытой крышке" и сотни пробников экспозиции, все равно очень много возни.

    а после применения lr _по_основному_назначению_ - у меня разобранная "коллекция", в которой не надо второй раз рыться - то что потом стоит медитации в фотошопе, помечено и покажется отдельно, то что не надо - убрано, остальное поконвертировано для веба в режиме "так сойдет" (но не факт что совпадающим с мнением автоматики, как именно "так")

    а возиться с единичным снимком я потом могу и в acr - чтоб лишний раз туда-сюда не переключаться.

     
  • 15.55, timur.davletshin (ok), 20:12, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Согласен, руководство администратора UNIX начала 2000 года не потеряло актуальности в своих ключевых моментрах касающихся архитектуры сетей и подходов в администрировании, но только с тех пор ушли в небытие почти или полностью половина из использовавшихся тогда ОС, уступили приоритетные позиции ключевые пакеты ПО на которых строится книга (sendmail, lpr, nis и пр.) и новичку начинать знакомство с тем, что он не сможет применить на практике или реализует это явно не лучшим образом, не стоит. Поэтому литературу стоит подбирать актуальную, особенно в таких "живых" темах как Lr.
     
  • 15.64, Crazy Alex (ok), 01:43, 17/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    Угу. Ничего не изменилось. HDR нет, панорамы тоже не возникли, всякие режимы полуавтоматической коррекции (нынче - ещё и со всяким распознаванием нейросетками) тоже...
     
     
  • 16.67, пох (?), 12:06, 17/09/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    если тебе это все нужно - в этом случае присоединяюсь к совету Тимура - не мучай лайтрум, тебе вообще ничего не надо кроме встроенной обработки в фотоаппарате. Он все это умеет, быстро, и для хипстаграмма сойдет. У новых-модных есть даже кнопочка "автоматически слить через ближайший wifi в хипстаграмчик".

    жаль что в том нет кнопки "ничего автоматически слитого не показывать никогда".

     
  • 3.12, timur.davletshin (ok), 11:24, 16/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    Попробуй как-нибудь на досуге в дождливый день сделать нижеприведённое и побенчмаркать до этого и после (сохранить в файл типа vacuum.sh, дать права доступа +х и ./vacuum.sh КАТАЛОГ_С_DB)

    #!/bin/bash

    find "$1" -type f -print0|while read -d $'\0' fname; do
    type='file -b "$fname"'
    case "$type" in
    SQLite*)
    echo "$fname"
    sqlite3 "$fname" "VACUUM;" || exit $?
    ;;
    esac
    done

     
  • 2.3, Аноним (2), 10:50, 16/09/2018 [^] [ответить]    [к модератору]  
  • +6 +/
    Ну и если вы применяете SQLite3 для каких-то таких задач, в которых фрагментация начинает иметь серьёзное влияние - вы однозначно что-то делаете не то и не так.
     
     
  • 3.4, timur.davletshin (ok), 11:04, 16/09/2018 [^] [ответить]    [к модератору]  
  • –5 +/
    Так это же функция БД, а простого разработчика, который просто её использует. Вот к примеру darktable хранит миниатюры (не знаю, кому эта светлая идея пришла) и настройки из всех sidecar файлов в sqlite базе данных. В моём случае это DB около 2 Gb, вроде бы и немного, но стоит сделать реэкспорт больше 1000 фоточек и лаги даже на SDD становятся заметными, предполагаю, что на HDD вообще кисло.
     
     
  • 4.5, timur.davletshin (ok), 11:05, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    <<не>> простого разработчика
     
  • 4.9, Аноним (9), 11:16, 16/09/2018 [^] [ответить]    [к модератору]  
  • +8 +/
    > Так это же функция БД, а простого разработчика

    - Моя Ока не справляется с перевозкой 60 тонн угля.
    - Что-то делаешь не так.
    - Так это же функция транспортного средства, а не простого водителя.

     
     
  • 5.10, timur.davletshin (ok), 11:20, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    >> Так это же функция БД, а простого разработчика
    > - Моя Ока не справляется с перевозкой 60 тонн угля.
    > - Что-то делаешь не так.
    > - Так это же функция транспортного средства, а не простого водителя.

    Дельное замечание, адресуй его разработчикам приложений, вроде Firefox и Chrome. Это для начала, т.к. те ещё относительно по-божески его используют.

     
     
  • 6.13, пох (?), 11:24, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    у меня нет никаких проблем с файрфоксом и хромым, вызванных sqlite - что я делаю не так?

     
     
  • 7.18, timur.davletshin (ok), 11:34, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Если бы проблемы не было, то разработчики FF не запилили бы аналогичную функцию в about:support :)

    Это ты просто об этом не знаешь или у тебя хранение истории в браузере ограничено несколькими месяцами. Если сомневаешься, то можешь загуглить "firefox sqlite slow" там тебе и про замедленный автокомплит расскажут и про убермедленную чистку истории.

     
     
  • 8.24, пох (?), 12:24, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    функция называется "integrity check", что как бы намекает нам...

    > Vacuum

    Initial database size is 12960 KiB
    + The database has been vacuumed
    Final database size is 12448 KiB
    > Statistics

    Database size is 12448 KiB

    не вижу проблемы.

    нет, я не храню историю от сотворения мира - все равно я уже не вспомню, что там было.

    понятно что есть странные люди которые делают какие-то странные вещи, но ни файрфокс, ни sqlite в этом не виноваты, на всех не наоптимизируешься.

     
     
  • 9.27, timur.davletshin (ok), 12:33, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Как я и сказал, ты или урезал срок хранения истории или не пользуешься им вовсе. У меня он ~70 Мб.
     
  • 8.34, НяшМяш (ok), 15:05, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Если бы проблема была, то разработчики FF запилили бы эту функцию примерно поверх адресной строки. Типичный юзер в жизни не знает про about:support. На том же core 2 duo ноутбучном в связке с ssd история за год с базой 40 мегабайт не тормозит - там уже лаги по другим причинам возникают.
     
     
  • 9.35, timur.davletshin (ok), 15:21, 16/09/2018 [^] [ответить]    [к модератору]  
  • –7 +/
    > Если бы проблема была, то разработчики FF запилили бы эту функцию примерно
    > поверх адресной строки. Типичный юзер в жизни не знает про about:support.
    > На том же core 2 duo ноутбучном в связке с ssd
    > история за год с базой 40 мегабайт не тормозит - там
    > уже лаги по другим причинам возникают.

    Озвучите причины? Ну просто для нас, для недалёких и сирых мещан в назидание.

     
  • 2.11, пох (?), 11:24, 16/09/2018 [^] [ответить]    [к модератору]  
  • +4 +/
    не переживай, innodb тоже тормозит, а про postgres и говорить не приходится (он еще и растет как на дрожжах при таком использовании).

    и лечится точно так же.

    причем дело не в фрагментации (не просто в фрагментации), на самом деле.

     
     
  • 3.14, timur.davletshin (ok), 11:25, 16/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    Да, я в курсе, нет в жизни счастья.
     
  • 2.15, MBG (?), 11:26, 16/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Давно бредите вслух? Пора к доктору. По теме: покажите воспроизводимый тест, тогда обсудим. В принципе, можно добиться деградации производительности любой файловой системы или базы данных, если постараться, но проблема, как правило, решается чтением документации.
     
     
  • 3.19, timur.davletshin (ok), 11:41, 16/09/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    > Давно бредите вслух? Пора к доктору. По теме: покажите воспроизводимый тест, тогда
    > обсудим. В принципе, можно добиться деградации производительности любой файловой системы
    > или базы данных, если постараться, но проблема, как правило, решается чтением
    > документации.

    Мне тебя учить цепляться утилитой sqlite3 к локальному *.sqlite файлу учить? Берёшь рабочий places.sqlite и делаешь 1000 произвольный SELECT'ов c index'ами, без них, по строкам и делаешь после VACUUM. Ну и размер файла не забудь замерить.

     
     
  • 4.29, Аноним (2), 14:11, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Ну и получаешь 0.02 сек вместо 0.01 сек. Да, аж на целых 100% производительность выросла, только вот кому оно интересно.
     
     
  • 5.30, Аноним (2), 14:11, 16/09/2018 [^] [ответить]    [к модератору]  
  • +/
    0.01 вместо 0.02, конечно же.
     
  • 5.33, timur.davletshin (ok), 14:55, 16/09/2018 [^] [ответить]    [к модератору]  
  • –5 +/
    Проходи мимо, оптимизации не для тебя, да и кремневый нож острее железного.
     
  • 4.65, MBG (?), 08:11, 17/09/2018 [^] [ответить]    [к модератору]  
  • +/
    У меня под рукой уйма SQLite баз размерами в десятки гигабайт и более - и все с ними отлично (реалтайм данные трафика с полмиллиона автомобилей или около того, порядка 10Гб данных ежечасно). Прежде чем пытаться меня учить, погугли мои патчи для оптимизации FTS в SQLite (сейчас сжатие индексов в апстриме), баг-репорты о некоторых проблемах на продакшен базах размером 5GB+ и проч. Так где тесты-то для заявленных проблем в SQLite?
     
     
  • 5.66, timur.davletshin (ok), 09:21, 17/09/2018 [^] [ответить]    [к модератору]  
  • –4 +/
    А... т.е. БД в 2 гигов не является уже Окой, везущей несколько тонн? Гуглить не буду, охотно верю заявлениям собеседника. Если вы всё умеете, то для вас не составит труда взять *.sqlite размером побольше, сдампить всё, потом восстановить и после побенчмаркать обе БД. Попробуйте, я гарантирую, что много нового узнаете для себя, с разработчиками всегда так. С нетерпением жду объяснений.
     
     
  • 6.98, Аноним (98), 17:50, 21/09/2018 [^] [ответить]    [к модератору]  
  • +/
    > Попробуйте, я гарантирую, что много нового узнаете для себя

    Ник MBG лет 10 уже наверное занимается sqlite, я думаю он в курсе :-)

     
  • 2.77, Кузя (?), 17:34, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Ключевая характеристика это СУБД в самом её названии -- Lite. Она не рассчитана на сколь-либо серьёзную нагрузку, а просто представляет удобное хранилище с широко знакомой многим семантикой.
    Не очень понимаю, как необходимость реиндексации, типичная для практически всех актуальных сейчас РСУБД, может затруднять обслуживание? Это как необходимость дышать воздухом затрудняет подводное плавание человека.
     
  • 1.7, Аноним (7), 11:09, 16/09/2018 [ответить] [показать ветку] [····]    [к модератору]  
  • +2 +/
    Вы все тут такие специалисты, а я вот сначала подумал, что решили добавить в базу данных графический сервер с поддержкой окон.
    Точнее это было первой шальной мыслью.
    Бред? Бред.
    (Сообщение сформулировано согласно политике открытых мыслей)
     
     
  • 2.8, Аноним (7), 11:14, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    В движок конечно, но это и без уточнений понятно.
     
  • 1.22, timur.davletshin (ok), 11:59, 16/09/2018 [ответить] [показать ветку] [····]    [к модератору]  
  • –3 +/
    Ы-ы-ы... ладно, здравой критики тут не понимают, поэтому ограничимся рандомным tips'ом на заданную тему.

    Делаем совместную базу данных NSS (сертификаты и ключи) для Firefox и Evolution. Исходим из того, что у вас стабильные версии FF и не самая древняя libnss.

    Делаем mkdir -p ~/.pki/nssdb && chmod 700 ~/.pki
    Заходим в каталог профиля своего FF и делаем перемещаем cert9.db и key4.db в ~/.pki/nssdb
    Далее из каталога профиля запускаем ln -s ~/.pki/nssdb/cert9.db . && ln -s ~/.pki/nssdb/key4.db .

    Вуа-ля — у вас общая БД, можно сделать аналогичное и с Thunderbird. При желании можно замержить соответствующие файлы из двух прог при помощи certutil.

     
     
  • 2.31, Аноним (2), 14:13, 16/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Потом один из них внезапно оказывается статически слинкованным с другой версией либы, и далее совет превращается в подобие вакууминга полуторакилобайтной базы sqlite3, только с более жёсткими последствиями.
     
     
  • 3.32, timur.davletshin (ok), 14:52, 16/09/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Почитайт для начала, почему циферка на единичку у этих файлов выросла и потом будешь "петь" про более жёсткие последствия.
     
  • 2.81, Кузя (?), 17:41, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Зачем? По-моему, вы не по назначению используете инструмент.
     
     
  • 3.83, timur.davletshin (ok), 17:51, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Ты о чём? О совместной базе для сертификатов вместо двух или трёх (LO тоже цепляет сертификаты для подписи документов)?
     
     
  • 4.86, Кузя (?), 18:01, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Да. Если нужно что-то совместное, то это не про SQLite. Вот и всё.
     
     
  • 5.87, timur.davletshin (ok), 18:04, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Это официальный способ его использовать, загугли NSS Shared DB.
     
     
  • 6.88, Кузя (?), 18:22, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Может и официальный, но толку-то.
     
     
  • 7.89, timur.davletshin (ok), 18:25, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Очевидно, ты просто не пользуешься сертификатами :)
     
     
  • 8.90, Кузя (?), 18:34, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Не, не пользуюсь. Но лайтом пользуюсь давно. Настолько, чтобы понять простую истину -- совместное использование и лайт это из разных песен.
     
     
  • 9.91, timur.davletshin (ok), 18:38, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    > Не, не пользуюсь. Но лайтом пользуюсь давно. Настолько, чтобы понять простую истину
    > -- совместное использование и лайт это из разных песен.

    А теперь расскажи о своём мнении мозилловцам. А то людям надо же как-то узнать об этом безусловно очень ценном мнении.

     
     
  • 10.92, Кузя (?), 19:00, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Мозиловцы, не пользуйтесь лайтом так, как вы им пользуетесь, не смущайте людей, а то они вам верят.
     
     
  • 11.93, timur.davletshin (ok), 19:04, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    А теперь к разрабам LO и Gnome.
     
     
  • 12.94, Кузя (?), 19:25, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Лайт это только хранилка. Что вы над ней накрутите -- ваше творчество. Лисонутые что-то не так, видимо, сделали. Бывает.
     
     
  • 13.95, timur.davletshin (ok), 19:40, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Так а что не так, я просто не понял. Или sqlite не поддерживает с каких-то пор уже multiple connections?
     
  • 1.37, пох (?), 16:05, 16/09/2018 [ответить] [показать ветку] [····]    [к модератору]  
  • –2 +/
    так, ну ладно, а по теме - кто-нибудь может показать реальный пример применения 'OVER' ?

     
     
  • 2.57, Аноним (57), 20:28, 16/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Можешь открыть доку в postgres по window functions и посмотреть.
     
     
  • 3.60, пох (?), 21:36, 16/09/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    я спрашивал "реальный пример" - где именно в жизни на реальных задачах оно у вас работает.
     
     
  • 4.68, Envek (ok), 21:28, 17/09/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Обычно нужно редко, для генерации всяких аналитических отчётов или для миграции данных, когда именно, что хочется взять и посчитать что-то «эдакое» одним запросом, потому что тащить в приложение и считать в памяти долго и муторно.

    Штука для понимания сложная, но когда овладеете этой отвёрткой, то охота забивать шурупы молотком отпадёт сама собой.

    Хорошая статья с примерами использования: https://habr.com/post/268983/
    Мой собственный очерк с примером миграции данных (очень меня оконные функции впечатлили): http://envek.name/ru/blog/2015/04/28/sql-window-functions
    И целый интерактивный сайт-тренажёр оконных функций: https://www.windowfunctions.com/

    P.S> Очень-очень рад тому, что поддержка оконных функций завезли в SQLite

     
     
  • 5.74, пох (?), 11:12, 19/09/2018 [^] [ответить]    [к модератору]  
  • +/
    спасибо огромное, а то когда на самом деле нужно - главное, в принципе сообразить что это шуруп, а не бракованный гвоздь - понимания чего "документация postgresql" по пользованию отверткой без живых примеров ни разу не даст.

     
  • 5.80, Кузя (?), 17:40, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Что там сложного-то?
     
  • 5.84, Кузя (?), 17:53, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Как раз таки нужно очень часто. Но это, да, синтаксическое упрощение, потому что и "обычными средствами" подобного результата можно достичь, но получится очень многословно.
     
  • 2.78, Кузя (?), 17:39, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    На любых агрегатных функциях. Без необходимости агрегации через group by. Очень удобно. На функциях ранжирования. На всяких набегающих значениях (сумма, счётчик по какой-нибудь категории).
     
  • 2.82, Кузя (?), 17:50, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Ну например, есть у вас, скажем, система регистрации событий. Типичная "строка" будет содержать дату/время события, категорию событий и текст сообщения события. И вам нужно найти по каждой категории строки с самыми старыми событиями. Можно сделать традиционным group by, а потом join, а можно сразу залепить окно по категории события и выбрать те строки, для которых значение самой старой даты в окне совпадёт со значением даты в строке события.
     
  • 1.58, Аноним (58), 21:16, 16/09/2018 [ответить] [показать ветку] [····]    [к модератору]  
  • –1 +/
    > При переименовании таблиц через "ALTER TABLE" реализовано автоматическое обновление всех ссылок на новое имя в триггерах и представлениях;

    Отлично! Ещё бы для столбцов того же. Очень экономит время при разработке схемы БД.

     
     
  • 2.61, пох (?), 21:39, 16/09/2018 [^] [ответить]    [к модератору]  
  • –4 +/
    вы ЭТО называете разработкой? "мы тут уже насоздавали сложных таблиц и отношений (раз понадобились уже и триггеры), залили пару гигабайт данных (иначе rm *sqlite решает проблему) - а теперь давайте пяток переименуем туда-сюда, и столбцы подвигаем, до кучи".

    где это такие разработчики, можно уточнить?

     
     
  • 3.70, Аноним (70), 03:10, 18/09/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Когда схему впервые проектируешь, удобнее делать это сразу в sqlite, а не на бумаге. Желая изменить имя чего-либо, приходится менять его везде вручную.
    О базах с реальными данными речи не идёт (впрочем, как и с кучами тестовых).
     
     
  • 4.75, нах (?), 10:59, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    странные у вас, право, идеи.
    (sqlite шелл и tab-completion-то нормально научился меньше года назад, и по сей день, мягко говоря, является скорее средством восстановления или отладки, а не удобным инструментом работы с базой)

    я вот проектирую не на бумаге, потому что ее неудобно потом скармливать тому же sqlite binary, а просто в текстовом редакторе - где хотя бы текстовая схема перед глазами, и ее не надо добывать противоестественным путем в форматировании для терминала. он же потом отправляется и в vcs.

    какой смысл запихивать ее в бинарный формат, если данных для  нее пока еще все равно нет, и кода пока тоже нет - не понимаю.

    и пока схема лежит в файле текстом - есть куда более простые и наглядные способы попереименовать в ней любые детали, нежели надеяться на еще толком недописанную автоматику внутри sqlite (на бумаге, заметьте, сильно неудобнее ;-)

    А вот когда база уже на сотенку гигабайт, и внезапно выяснилось что 'термин "всякая фигня" не вполне точно отражает весь спектр товаров и услуг, предлагаемых нашей компанией' и надо в небольшое окно простоя поменять в ней "немножечко" структуру, желательно не перестраивая все индексы и уж тем более не делая store/load - вот тут alter table альтернативы и правда нет. То есть фича безусловно полезная, но для разработки ее применять ну очень странно.

     
  • 1.69, Аноним (69), 21:57, 17/09/2018 [ответить] [показать ветку] [····]    [к модератору]  
  • –2 +/
    Когда уже будет sqlite в MySQL реализован как хранилище? Было бы удобно использовать по сети и несколькими пользователями. Может уже кто-то сделал?
     
     
  • 2.76, нах (?), 11:05, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    для посети и несколькимпользователям давным-давно выдуман sqlproxy, если вы так и не осилили серверный middleware, и каждый пользователь у вас по прежнему лазит напрямую в базу (привет, жаббикс).

    а удобно будет, когда кто-нибудь сумеет совместить libsqlite3 с каким-то другим хранилищем, поскольку болячки локинга как раз в нем. (ничего не мешает сохранить его файловым, унеся локинг и journal management в пространство systemV, кроме, конечно же, интересов мурзилы, адоба и, возможно, блумберга)

     
     
  • 3.85, Кузя (?), 17:57, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Ё-маё, зачем? SQLite нужен исключительно как простая однопользовательская интегрируемая файловая хранилка, но использующая SQL. Всё. Больше она ни для чего не нужна, потому для прочего полно куда более адекватных СУБД.
     
     
  • 4.96, пох (?), 19:49, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    > Ё-маё, зачем? SQLite нужен исключительно как простая однопользовательская интегрируемая
    > файловая хранилка, но использующая SQL.
    > Всё. Больше она ни для чего не нужна, потому для прочего полно куда более адекватных СУБД.

    куда более неадекватных, в этом и дело. Давно вы на ora-0006 не напарывались, погляжу?

    у sqlite в общем-то сейчас есть почти все, что есть у этих неадекватных, кроме разьве что навороченного plsql, который вполне можно оставить орацлу. А простые хранилки как-то до наших дней не дожили, кто еще помнит raima?
    А никаких чудес у тех давно уже нет - все те же файлики все в той же файловой системе (ибо block devices тоже уже нигде нормальных нет), где чудо? - не вижу, уже очки два раза протирал. Авторизацию просохатили (в смысле - надежную, которую не требуется прикрывать от внешнего мира салфеточкой) даже у кого была, вся "многопользовательскость" у них только в том, что разные тредики кое-как умеют в синхронизацию, не требующую задействовать совершенно неэффективные posix locks на уровне фс. Ну так в posix есть не только fs локи, и "многопользовательскость" вполне реализуема и межпроцессная. tcp и unix sockets - не нужны, авторы "адекватных" все равно работают с ними омерзительно неэффективно, оставьте сетевые задачи прокси.

    но вот тут да, ньюанс - под виндой работать не будет. А ентого мурзила не поймет-с.

     
     
  • 5.99, Мудила (?), 14:23, 22/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Это из разряда, что Люксембург -- прекрасное государство, в нём есть всё. Кроме жителей и территории.
    На 0006Х никогда не напарывался. Это не проблема оракла, а проблема проектирования схемы. Если всё спроектировано хотя бы с минимальным пониманием темы, то "дедлока" в оракле вы не увидите никогда.
     
  • 2.79, Кузя (?), 17:39, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    Зачем? Дельфин вообще не нужен.
     
     
  • 3.97, пох (?), 19:52, 20/09/2018 [^] [ответить]    [к модератору]  
  • +/
    > Зачем? Дельфин вообще не нужен.

    а как же мы будем данные с пехепе фронтенда снимать? А, ну да, есть же еще какая-то pinba-mq поделка... или недоделка?

    а так да... sorting tmp table, 20 лет все те же грабли.

     

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


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