Представлен (https://www.mail-archive.com/sqlite-announce@sqlite.org...) релиз SQLite 3.25.0 (http://sqlite.org/), легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg.Основные изменения (https://sqlite.org/releaselog/3_25_0.html):
- Добавлена поддержка оконных функций (https://sqlite.org/windowfunctions.html) (window-функции или аналитические функции), позволяющих для каждой строки запроса выполнить вычисления, используя другие строки. В отличие от агрегатных функций, которые свёртывают сгруппированный набор строк в одну строку, оконные функции производят агрегирование на основе содержимого "окна", включающего одну или более строк из результирующего набора;- Добавлена поддержка переименования столбцов при помощи команды "ALTER TABLE table RENAME COLUMN oldname TO newname (https://sqlite.org/lang_altertable.html)";
- При переименовании таблиц через "ALTER TABLE" реализовано автоматическое обновление всех ссылок на новое имя в триггерах и представлениях;
- В состав включён новый модуль Geopoly (https://sqlite.org/geopoly.html) с реализацией альтернативного интерфейса к 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;
- Устранена ошибка (https://www.sqlite.org/src/info/9936b2fa443fec03ff25), которая при редком стечении обстоятельств могла привести к бесконечному зацикливанию в движке генерации байткода при выполнении оптимизации конструкции "ORDER BY LIMIT".
URL: https://www.mail-archive.com/sqlite-announce@sqlite.org...
Новость: https://www.opennet.me/opennews/art.shtml?num=49282
Эх, всё бы было классно с этой sqlite, если бы она тормозить не начинала из-за фрагментации через какое-то время активного использования. А то VACUUM+REINDEX ломает запускать регулярно. На десктопе ещё ладно, это можно сделать, но они же его и на мобильные устройства запихивает во все места. Что с одной стороны оправдано, а с другой затрудняет обслуживание.
На мобильных устройствах в основном флэш, им фрагментация фиолетова.
И пухнущая DB c кучей dead tuples тоже им фиолетова. Мне кажется, что такие люди, как ты, в этих случаях бегут покупать новый телефон, т.к. старый "после обновления вообще тупить стал". Зацепись в режиме разработчика через adb shell и посмотри на это позорище до VACUUM+REINDEX и после.
> И пухнущая DB c кучей dead tuples тоже им фиолетова.тоже.
во всяком случае, пока "куча" не превышает разумных размеров. Что будет, если пихать в нее картинки по 20 мегапикселей - я, правда, не знаю, у меня есть вполне себе нормальная lightroom, я не нуждаюсь в пионерских подделках.
Ой да ладно, LR не тормозит у него. Басни тоже мне рассказываешь. Оно уже OpenCL научилось или всё продолжает камень насиловать?
не знаю, у меня нет поддержки opencl на той системе, где я вожусь с lr.
при ее workflow все основное торможение происходит, когда все кнопки уже нажаты и я ушел от клавиатуры.
Я вам искренне сочувствую, т.к. работать без ускорения на GPU — тратить в ~5 раз больше времени (лично у меня) на генерацию preview и экспорт файлов. А на современных камерах с 24+ MPx это вообще становится адом.
машина - она железная. Флэшку засовываешь, идешь обедать - оно копируется и генерит свои превьюшки. export делается батчем, и идешь спать. Утром, наверное, сгенерит - но проверять мы это не будем, пора на работу.а если надо долго возиться с конкретным снимком - все равно понадобится фотошоп. Который тормозит много где, и никакое gpu ему радикально не помогает - какие-то операции будут побыстрее, каким-то не поможет.
чтобы стало заметно быстрее - надо менять все железо по кругу, не только видео, ставить распоследние версии всего (которые уже не продаются а даются на время подержать двумя пальчкиками)... в общем, не будучи в этом профессионалом, не вижу смысла заморачиваться.
Вы реально считаете, что для такого workflow нужен LR? Я бы рекомендовал вам открыть для себя всё-таки мощь GPU — на электричестве сэкономите, да и жужик, молотящий на всю слушать не особо приятно.
да. он только под такой и заточен.
это средство массовой обработки по шаблону, а не детальной возни с каждым снимком.
> да. он только под такой и заточен.
> это средство массовой обработки по шаблону, а не детальной возни с каждым
> снимком.ORLY?! То-то я смотрю интернеты пестрят мануалами по детальной возне с со всеми этими движочками и по художественной обработке.
де6илов - которым еще и нужны "мануалы в интернетах", ибо нормальную литературу осилить они не могут - полно.движки эти выставляют обычно один раз под серию снимков в примерно одинаковом свете - очень часто это вообще все, что делается в самом LR. Оно именно на такой подход и рассчитано.
если кому-то понадобилось сначала купить(недешево) профессиональный инструмент, а потом забивать им гвозди - адоба не возражает, продаваны cuda-capable видеокарт тоже. Кто-то этим лохам еще и, вот, инструкцию по удобному держанию микроскопа для забивания гвоздя продает.
> де6илов - которым еще и нужны "мануалы в интернетах", ибо нормальную литературу
> осилить они не могут - полно.
> движки эти выставляют обычно один раз под серию снимков в примерно одинаковом
> свете - очень часто это вообще все, что делается в самом
> LR. Оно именно на такой подход и рассчитано.
> если кому-то понадобилось сначала купить(недешево) профессиональный инструмент, а потом
> забивать им гвозди - адоба не возражает, продаваны cuda-capable видеокарт тоже.
> Кто-то этим лохам еще и, вот, инструкцию по удобному держанию микроскопа
> для забивания гвоздя продает.Нормальная литература для таких инструментов быстро теряет актуальность, т.к. от написания книги, до её покупки читатателем проходит около года или больше.
Да не пыхти там, все так обрабатывают большие объёмы. Только индивидуально потом кроп, коррекция горизонта и прочие изыски вроде удаления пятен на объективе и пр.
Касательно иронии на предмет GPU: я так понял, что производительность тебя не интересует. Но это для твоего брата нормально.
> Нормальная литература для таких инструментов быстро теряет актуальностьнормальная литература для таких инструментов написана хрен знает когда. Ничего с тех пор в фотографии глобально не изменилось, отдельные мелочи, мало влияющие на результат. Тем более что LR старательно воспроизводит работу с фотоматериалами, про которую книги написали еще в прошлом веке.
> Касательно иронии на предмет GPU: я так понял, что производительность тебя не интересует.
сферическая в вакууме - нет, не интересует, меня интересует производительность меня, а она от gpu мало увеличится. Ночь потом эта коробка будет батч переваривать или пол-ночи - совершенно пофигу, особенно за мои деньги.
У меня складывается впечатление, что вам встроенного в камеру преобразования raw в JPG за глаза хватит, там тоже можно яркость/HDR/дисторсию править и пакетом всё преобразовывать. И, что самоё главное, там за секунды это делается."Lr старательно воспроизводит работу с фотоматериалами?" — да ладно, там уже есть профили "под плёнки Konica, AGFA" и прочее? У меня всё больше складывается мнение, что вы им плоховато владеете.
у меня сложилось впечатление, что в фотографии вы полнейший дилетант.
поэтому не вижу смысла тратить на вас время.
Ну пока что больше информации для выводов предоставил ты, а не я.
> Ну пока что больше информации для выводов предоставил ты, а не я.Ошибаетесь - в принципе очевидно, что вы не заморачивались обработкой фоточек.
Я только не понял зачем ваш оппонент использует какой-то лайтрум, когда есть нормальный rawtherapee.
А в rawtherapee уже завезли маски и кисти, там можно хотя бы пятна на объективе/сенсоре убрать? Ну, специалист по фоточкам, ответишь? Я уже не говорю о его интерфейсе и отсутствии аппаратного ускорения и однопоточность многих модулей. Нет, я не говорю, что он плох, там есть ряд очень качественных с точки зрения качества кода модулей (поэтому их и юзают в сторонних проектах), но есть и ряд серьёзных просчётов.
дык, то же ж самое - rawtherapee, даже если абстрагироваться от ее болезней связанных с не самым лучшим парсингом собственно равов и не самыми хорошими алгоритмами поверх него - не очень удобна, когда надо разобрать пять сотен фоток из очередной поездки в теплые края - предположим даже, я буду использовать что-нибудь типа frv для удаления "снимок сделан при закрытой крышке" и сотни пробников экспозиции, все равно очень много возни.а после применения lr _по_основному_назначению_ - у меня разобранная "коллекция", в которой не надо второй раз рыться - то что потом стоит медитации в фотошопе, помечено и покажется отдельно, то что не надо - убрано, остальное поконвертировано для веба в режиме "так сойдет" (но не факт что совпадающим с мнением автоматики, как именно "так")
а возиться с единичным снимком я потом могу и в acr - чтоб лишний раз туда-сюда не переключаться.
Согласен, руководство администратора UNIX начала 2000 года не потеряло актуальности в своих ключевых моментрах касающихся архитектуры сетей и подходов в администрировании, но только с тех пор ушли в небытие почти или полностью половина из использовавшихся тогда ОС, уступили приоритетные позиции ключевые пакеты ПО на которых строится книга (sendmail, lpr, nis и пр.) и новичку начинать знакомство с тем, что он не сможет применить на практике или реализует это явно не лучшим образом, не стоит. Поэтому литературу стоит подбирать актуальную, особенно в таких "живых" темах как Lr.
Угу. Ничего не изменилось. HDR нет, панорамы тоже не возникли, всякие режимы полуавтоматической коррекции (нынче - ещё и со всяким распознаванием нейросетками) тоже...
если тебе это все нужно - в этом случае присоединяюсь к совету Тимура - не мучай лайтрум, тебе вообще ничего не надо кроме встроенной обработки в фотоаппарате. Он все это умеет, быстро, и для хипстаграмма сойдет. У новых-модных есть даже кнопочка "автоматически слить через ближайший wifi в хипстаграмчик".жаль что в том нет кнопки "ничего автоматически слитого не показывать никогда".
Попробуй как-нибудь на досуге в дождливый день сделать нижеприведённое и побенчмаркать до этого и после (сохранить в файл типа 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
Ну и если вы применяете SQLite3 для каких-то таких задач, в которых фрагментация начинает иметь серьёзное влияние - вы однозначно что-то делаете не то и не так.
Так это же функция БД, а простого разработчика, который просто её использует. Вот к примеру darktable хранит миниатюры (не знаю, кому эта светлая идея пришла) и настройки из всех sidecar файлов в sqlite базе данных. В моём случае это DB около 2 Gb, вроде бы и немного, но стоит сделать реэкспорт больше 1000 фоточек и лаги даже на SDD становятся заметными, предполагаю, что на HDD вообще кисло.
<<не>> простого разработчика
> Так это же функция БД, а простого разработчика- Моя Ока не справляется с перевозкой 60 тонн угля.
- Что-то делаешь не так.
- Так это же функция транспортного средства, а не простого водителя.
>> Так это же функция БД, а простого разработчика
> - Моя Ока не справляется с перевозкой 60 тонн угля.
> - Что-то делаешь не так.
> - Так это же функция транспортного средства, а не простого водителя.Дельное замечание, адресуй его разработчикам приложений, вроде Firefox и Chrome. Это для начала, т.к. те ещё относительно по-божески его используют.
у меня нет никаких проблем с файрфоксом и хромым, вызванных sqlite - что я делаю не так?
Если бы проблемы не было, то разработчики FF не запилили бы аналогичную функцию в about:support :)Это ты просто об этом не знаешь или у тебя хранение истории в браузере ограничено несколькими месяцами. Если сомневаешься, то можешь загуглить "firefox sqlite slow" там тебе и про замедленный автокомплит расскажут и про убермедленную чистку истории.
функция называется "integrity check", что как бы намекает нам...> Vacuum
Initial database size is 12960 KiB
+ The database has been vacuumed
Final database size is 12448 KiB
> StatisticsDatabase size is 12448 KiB
не вижу проблемы.
нет, я не храню историю от сотворения мира - все равно я уже не вспомню, что там было.
понятно что есть странные люди которые делают какие-то странные вещи, но ни файрфокс, ни sqlite в этом не виноваты, на всех не наоптимизируешься.
Как я и сказал, ты или урезал срок хранения истории или не пользуешься им вовсе. У меня он ~70 Мб.
Если бы проблема была, то разработчики FF запилили бы эту функцию примерно поверх адресной строки. Типичный юзер в жизни не знает про about:support. На том же core 2 duo ноутбучном в связке с ssd история за год с базой 40 мегабайт не тормозит - там уже лаги по другим причинам возникают.
> Если бы проблема была, то разработчики FF запилили бы эту функцию примерно
> поверх адресной строки. Типичный юзер в жизни не знает про about:support.
> На том же core 2 duo ноутбучном в связке с ssd
> история за год с базой 40 мегабайт не тормозит - там
> уже лаги по другим причинам возникают.Озвучите причины? Ну просто для нас, для недалёких и сирых мещан в назидание.
не переживай, innodb тоже тормозит, а про postgres и говорить не приходится (он еще и растет как на дрожжах при таком использовании).и лечится точно так же.
причем дело не в фрагментации (не просто в фрагментации), на самом деле.
Да, я в курсе, нет в жизни счастья.
Давно бредите вслух? Пора к доктору. По теме: покажите воспроизводимый тест, тогда обсудим. В принципе, можно добиться деградации производительности любой файловой системы или базы данных, если постараться, но проблема, как правило, решается чтением документации.
> Давно бредите вслух? Пора к доктору. По теме: покажите воспроизводимый тест, тогда
> обсудим. В принципе, можно добиться деградации производительности любой файловой системы
> или базы данных, если постараться, но проблема, как правило, решается чтением
> документации.Мне тебя учить цепляться утилитой sqlite3 к локальному *.sqlite файлу учить? Берёшь рабочий places.sqlite и делаешь 1000 произвольный SELECT'ов c index'ами, без них, по строкам и делаешь после VACUUM. Ну и размер файла не забудь замерить.
Ну и получаешь 0.02 сек вместо 0.01 сек. Да, аж на целых 100% производительность выросла, только вот кому оно интересно.
0.01 вместо 0.02, конечно же.
Проходи мимо, оптимизации не для тебя, да и кремневый нож острее железного.
У меня под рукой уйма SQLite баз размерами в десятки гигабайт и более - и все с ними отлично (реалтайм данные трафика с полмиллиона автомобилей или около того, порядка 10Гб данных ежечасно). Прежде чем пытаться меня учить, погугли мои патчи для оптимизации FTS в SQLite (сейчас сжатие индексов в апстриме), баг-репорты о некоторых проблемах на продакшен базах размером 5GB+ и проч. Так где тесты-то для заявленных проблем в SQLite?
А... т.е. БД в 2 гигов не является уже Окой, везущей несколько тонн? Гуглить не буду, охотно верю заявлениям собеседника. Если вы всё умеете, то для вас не составит труда взять *.sqlite размером побольше, сдампить всё, потом восстановить и после побенчмаркать обе БД. Попробуйте, я гарантирую, что много нового узнаете для себя, с разработчиками всегда так. С нетерпением жду объяснений.
> Попробуйте, я гарантирую, что много нового узнаете для себяНик MBG лет 10 уже наверное занимается sqlite, я думаю он в курсе :-)
Ключевая характеристика это СУБД в самом её названии -- Lite. Она не рассчитана на сколь-либо серьёзную нагрузку, а просто представляет удобное хранилище с широко знакомой многим семантикой.
Не очень понимаю, как необходимость реиндексации, типичная для практически всех актуальных сейчас РСУБД, может затруднять обслуживание? Это как необходимость дышать воздухом затрудняет подводное плавание человека.
Вы все тут такие специалисты, а я вот сначала подумал, что решили добавить в базу данных графический сервер с поддержкой окон.
Точнее это было первой шальной мыслью.
Бред? Бред.
(Сообщение сформулировано согласно политике открытых мыслей)
В движок конечно, но это и без уточнений понятно.
Ы-ы-ы... ладно, здравой критики тут не понимают, поэтому ограничимся рандомным 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.
Потом один из них внезапно оказывается статически слинкованным с другой версией либы, и далее совет превращается в подобие вакууминга полуторакилобайтной базы sqlite3, только с более жёсткими последствиями.
Почитайт для начала, почему циферка на единичку у этих файлов выросла и потом будешь "петь" про более жёсткие последствия.
Зачем? По-моему, вы не по назначению используете инструмент.
Ты о чём? О совместной базе для сертификатов вместо двух или трёх (LO тоже цепляет сертификаты для подписи документов)?
Да. Если нужно что-то совместное, то это не про SQLite. Вот и всё.
Это официальный способ его использовать, загугли NSS Shared DB.
Может и официальный, но толку-то.
Очевидно, ты просто не пользуешься сертификатами :)
Не, не пользуюсь. Но лайтом пользуюсь давно. Настолько, чтобы понять простую истину -- совместное использование и лайт это из разных песен.
> Не, не пользуюсь. Но лайтом пользуюсь давно. Настолько, чтобы понять простую истину
> -- совместное использование и лайт это из разных песен.А теперь расскажи о своём мнении мозилловцам. А то людям надо же как-то узнать об этом безусловно очень ценном мнении.
Мозиловцы, не пользуйтесь лайтом так, как вы им пользуетесь, не смущайте людей, а то они вам верят.
А теперь к разрабам LO и Gnome.
Лайт это только хранилка. Что вы над ней накрутите -- ваше творчество. Лисонутые что-то не так, видимо, сделали. Бывает.
Так а что не так, я просто не понял. Или sqlite не поддерживает с каких-то пор уже multiple connections?
так, ну ладно, а по теме - кто-нибудь может показать реальный пример применения 'OVER' ?
Можешь открыть доку в postgres по window functions и посмотреть.
я спрашивал "реальный пример" - где именно в жизни на реальных задачах оно у вас работает.
Обычно нужно редко, для генерации всяких аналитических отчётов или для миграции данных, когда именно, что хочется взять и посчитать что-то «эдакое» одним запросом, потому что тащить в приложение и считать в памяти долго и муторно.Штука для понимания сложная, но когда овладеете этой отвёрткой, то охота забивать шурупы молотком отпадёт сама собой.
Хорошая статья с примерами использования: https://habr.com/post/268983/
Мой собственный очерк с примером миграции данных (очень меня оконные функции впечатлили): http://envek.name/ru/blog/2015/04/28/sql-window-functions
И целый интерактивный сайт-тренажёр оконных функций: https://www.windowfunctions.com/P.S> Очень-очень рад тому, что поддержка оконных функций завезли в SQLite
спасибо огромное, а то когда на самом деле нужно - главное, в принципе сообразить что это шуруп, а не бракованный гвоздь - понимания чего "документация postgresql" по пользованию отверткой без живых примеров ни разу не даст.
Что там сложного-то?
Как раз таки нужно очень часто. Но это, да, синтаксическое упрощение, потому что и "обычными средствами" подобного результата можно достичь, но получится очень многословно.
На любых агрегатных функциях. Без необходимости агрегации через group by. Очень удобно. На функциях ранжирования. На всяких набегающих значениях (сумма, счётчик по какой-нибудь категории).
Ну например, есть у вас, скажем, система регистрации событий. Типичная "строка" будет содержать дату/время события, категорию событий и текст сообщения события. И вам нужно найти по каждой категории строки с самыми старыми событиями. Можно сделать традиционным group by, а потом join, а можно сразу залепить окно по категории события и выбрать те строки, для которых значение самой старой даты в окне совпадёт со значением даты в строке события.
> При переименовании таблиц через "ALTER TABLE" реализовано автоматическое обновление всех ссылок на новое имя в триггерах и представлениях;Отлично! Ещё бы для столбцов того же. Очень экономит время при разработке схемы БД.
вы ЭТО называете разработкой? "мы тут уже насоздавали сложных таблиц и отношений (раз понадобились уже и триггеры), залили пару гигабайт данных (иначе rm *sqlite решает проблему) - а теперь давайте пяток переименуем туда-сюда, и столбцы подвигаем, до кучи".где это такие разработчики, можно уточнить?
Когда схему впервые проектируешь, удобнее делать это сразу в sqlite, а не на бумаге. Желая изменить имя чего-либо, приходится менять его везде вручную.
О базах с реальными данными речи не идёт (впрочем, как и с кучами тестовых).
странные у вас, право, идеи.
(sqlite шелл и tab-completion-то нормально научился меньше года назад, и по сей день, мягко говоря, является скорее средством восстановления или отладки, а не удобным инструментом работы с базой)я вот проектирую не на бумаге, потому что ее неудобно потом скармливать тому же sqlite binary, а просто в текстовом редакторе - где хотя бы текстовая схема перед глазами, и ее не надо добывать противоестественным путем в форматировании для терминала. он же потом отправляется и в vcs.
какой смысл запихивать ее в бинарный формат, если данных для нее пока еще все равно нет, и кода пока тоже нет - не понимаю.
и пока схема лежит в файле текстом - есть куда более простые и наглядные способы попереименовать в ней любые детали, нежели надеяться на еще толком недописанную автоматику внутри sqlite (на бумаге, заметьте, сильно неудобнее ;-)
А вот когда база уже на сотенку гигабайт, и внезапно выяснилось что 'термин "всякая фигня" не вполне точно отражает весь спектр товаров и услуг, предлагаемых нашей компанией' и надо в небольшое окно простоя поменять в ней "немножечко" структуру, желательно не перестраивая все индексы и уж тем более не делая store/load - вот тут alter table альтернативы и правда нет. То есть фича безусловно полезная, но для разработки ее применять ну очень странно.
Когда уже будет sqlite в MySQL реализован как хранилище? Было бы удобно использовать по сети и несколькими пользователями. Может уже кто-то сделал?
для посети и несколькимпользователям давным-давно выдуман sqlproxy, если вы так и не осилили серверный middleware, и каждый пользователь у вас по прежнему лазит напрямую в базу (привет, жаббикс).а удобно будет, когда кто-нибудь сумеет совместить libsqlite3 с каким-то другим хранилищем, поскольку болячки локинга как раз в нем. (ничего не мешает сохранить его файловым, унеся локинг и journal management в пространство systemV, кроме, конечно же, интересов мурзилы, адоба и, возможно, блумберга)
Ё-маё, зачем? SQLite нужен исключительно как простая однопользовательская интегрируемая файловая хранилка, но использующая SQL. Всё. Больше она ни для чего не нужна, потому для прочего полно куда более адекватных СУБД.
> Ё-маё, зачем? SQLite нужен исключительно как простая однопользовательская интегрируемая
> файловая хранилка, но использующая SQL.
> Всё. Больше она ни для чего не нужна, потому для прочего полно куда более адекватных СУБД.куда более неадекватных, в этом и дело. Давно вы на ora-0006 не напарывались, погляжу?
у sqlite в общем-то сейчас есть почти все, что есть у этих неадекватных, кроме разьве что навороченного plsql, который вполне можно оставить орацлу. А простые хранилки как-то до наших дней не дожили, кто еще помнит raima?
А никаких чудес у тех давно уже нет - все те же файлики все в той же файловой системе (ибо block devices тоже уже нигде нормальных нет), где чудо? - не вижу, уже очки два раза протирал. Авторизацию просохатили (в смысле - надежную, которую не требуется прикрывать от внешнего мира салфеточкой) даже у кого была, вся "многопользовательскость" у них только в том, что разные тредики кое-как умеют в синхронизацию, не требующую задействовать совершенно неэффективные posix locks на уровне фс. Ну так в posix есть не только fs локи, и "многопользовательскость" вполне реализуема и межпроцессная. tcp и unix sockets - не нужны, авторы "адекватных" все равно работают с ними омерзительно неэффективно, оставьте сетевые задачи прокси.но вот тут да, ньюанс - под виндой работать не будет. А ентого мурзила не поймет-с.
Это из разряда, что Люксембург -- прекрасное государство, в нём есть всё. Кроме жителей и территории.
На 0006Х никогда не напарывался. Это не проблема оракла, а проблема проектирования схемы. Если всё спроектировано хотя бы с минимальным пониманием темы, то "дедлока" в оракле вы не увидите никогда.
Зачем? Дельфин вообще не нужен.
> Зачем? Дельфин вообще не нужен.а как же мы будем данные с пехепе фронтенда снимать? А, ну да, есть же еще какая-то pinba-mq поделка... или недоделка?
а так да... sorting tmp table, 20 лет все те же грабли.