| 1.1, zo0M (ok), 08:16, 05/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –23 +/– |
 Достойный соперник Oracle Database. Эта битва будет легендарной!
| | |
| |
| 2.3, Аноним (3), 08:41, 05/10/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Той самой орацле-датабазе, что использует BerkleyDB для хранения своих метаданных, кстати.
| | |
| |
| |
| 4.7, x3who (?), 11:49, 05/10/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
Тот самый Oracle, что участвует в финансировании СУБД SQLite
| | |
|
|
| 2.30, Учоная Жывотная (?), 05:49, 07/10/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> соперник Oracle Database
Ви унилый поц. Жить в 46 лет с мамочкой нормально. Но когда мама в 46 ваших лет ставит вам клизмачки, этого таки я немогу одобрить!
| | |
|
| 1.6, Murz (ok), 09:16, 05/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
 Bentley? Это которая недорогие автомобильчики делает, работающие на sqlite и бабле? ;)
| | |
| |
| 2.11, Аноним (11), 15:11, 05/10/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Не нужна нам такая свобода, завтра автора не будет и корпорации с чистой совестью наклепают своих несовместимых проприетарных форков. И ладно бы до пользователей не дошло, так они ж продавать начнут.
| | |
| |
| 3.12, Аноним (12), 16:26, 05/10/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Во-первых, отучаемся говорить за всех.
Во-вторых, учимся адекватно воспринимать реальность: "корпорациям" и сейчас ничего не мешает так поступить. Вместо этого они совместно финансируют разработку.
| | |
| |
| |
| 5.24, Аноним (12), 07:35, 06/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Не,я конечно не за всех говорю, только за здравомыслящих.
То есть ты не понял, что манипуляции в данном случае не прокатывают, и продолжаешь выдавать примитив.
> Уже сегодня есть
> всякие сторонние проприетарные расширения типа вот этой шляпы
И что?
| | |
|
|
| 3.14, Ан (??), 18:09, 05/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
И то бы ладно. Да запатентуют потом наработки и потеряют все.
| | |
|
| 2.26, Аноним (26), 15:42, 06/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это да, но с SQLite есть одна огромная проблема - автор не принимает запросы на слияние вообще. Нужна фича - либо заплати автору за её реализацию, либо поддерживай свой форк до тех пор, пока не решишь, что лучше забить. Аргументация автора в том, что он продаёт бумажки о том, что код не нарушает ни чей копирайт за круглую сумму (потому что если код нарушает копирайт, даже если техногиганты не виноваты, им придётся его исключить, а это многомиллиардные убытки, а те смехотворные для гигантов суммы, какие автор запрашивает они бы всё равно бы дали и даже больше, потому что зависят от продукта и им невыгодно, чтобы он заглох), и что единственный способ это гарантировать - иметь только код, написанный лично.
| | |
| |
| 3.29, Аноним (29), 21:14, 06/10/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> автор не принимает запросы на слияние вообще
Никакая лицензия не заставляет авторов принимать пулл-реквесты,
| | |
| 3.32, MBG (?), 11:48, 07/10/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Зато автор рассматривает присылаемые патчи и переписывает их сам, если удастся убедить, в чем их польза. В свое время я достаточно долго с Ричардом обсуждал добавление сжатия FTS-индекса и он это реализовал в коде - хотя и не так, как было сделано в моих патчах, но какая разница.
| | |
|
|
| 1.13, Нуб (?), 17:53, 05/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
поясните новичку, в каких условиях требуется использования сабжа? Когда жсон уже тормозит, а здоровенные бд не имеют смысла (ибо клиентское приложение)?
| | |
| |
| 2.15, Аноним (15), 18:29, 05/10/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
У електронщиков бытует легенда, что когда жсон начинает тормозить, пора менять датацентр.
| | |
| |
| 3.28, Аноним (26), 15:50, 06/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
> не платить за хостинг
> потом хостинг начинает шантажировать владельцев приложений, а сайты тех, кто не заплатил, удаляет вместе с базой, не дав выгрузить данные. В лучшем случае. | | |
|
| 2.22, Аноним (10), 22:45, 05/10/2019 [^] [^^] [^^^] [ответить]
| –4 +/– |
Извините, я новичок. Что это за база данных - "САБЖ"? И чем он лучше sqlite?
| | |
| 2.23, Аноним (23), 03:04, 06/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Когда жсон уже тормозит
когда ещё не успел подцепить и интернетах жсон головного мозга, а локальная база нужна.
| | |
| 2.25, Онаним (?), 11:33, 06/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда ты хочешь SQL, но без гребли и охоты с внешним сервером.
| | |
| 2.27, Аноним (26), 15:44, 06/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда нужна быстрая встраиваемая база данных с SQL. Когда нужно мегатупое key-value хранилище, то есть и получше альтернативы.
| | |
|
| 1.31, Аноним (31), 08:44, 07/10/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
SQLite, расшаренная на десrтопе на SSD в типичном режиме работы:
- 1 поток записи (5% времени)
- 4 потока чтения по сети 1GB LAN через ODBC/JDBC (20% времени)
- простой (75% времени)
оказывается в 3-4 раза быстрее по отклику и скорости выполнения SQL-запросом чем в тех же условиях та же база на MS Access, HSQLDB, MySQL, PostgreSQL, FireBird. База 1 Гб, 100 полей х 3000000 строк
Работа с SQLite с WAL из Python - оказывается еще быстрее раза в два. Честно говоря, ничего быстрее я не знаю и скорее всего что быстрее ничего нет. Все дело в указателях файла. IN-MEMORY она тоже умеет, но это не в счет.
| | |
| |
| 2.33, MBG (?), 11:51, 07/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это у вас 1GB сеть тормозит :) Ну или Btree индексы слишком активно используете...
| | |
| |
| 3.34, Аноним (31), 13:05, 07/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Сеть не тормозит, один сегмент. Индексы используем обычные (аналитика бухучета по субконто - названия Контрагентов, Материалов итп). Серверные СУБД медленнее SQLite просто потому что заняты предотвращением конфликтов записи и проверкой типов. SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё.
| | |
| |
| 4.35, MBG (?), 20:27, 07/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
"в 3-4 раза быстрее" - это ерунда, потому что на сложных селектах из многих таблиц можно и на 3-4 порядка (десятичных) выигрыш получить. При условии, что статистика таблиц собрана правильно или сгенерирована (эскулайт умеет сохранить и загрузить статистику для планировщика). А вот в постресе, к примеру, объединение десятков таблиц или сложные коррелированные подзапросы требуют шаманства для получения правильного плана выполнения. Особенно, когда речь идет о пространственных данных и модулях PostGIS vs Spatialite.
| | |
| 4.36, MBG (?), 20:39, 07/10/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Медленнее, но не поэтому. При доступе только на чтение без блокировок нет никаких "конфликтов записи".
> "SQLite если и читает во время записи - просто шлет таймаут клиенту на 1 сек. и всё. "
Не обязательно, есть разные варианты работы. Смотрите WAL-режим, чтение "грязных" данных и проч. настройки. Так что можно и без таймаутов обходиться.
Рекомендую вот это почитать:
https://www.sqlite.org/queryplanner-ng.html
Ну и вдобавок
https://sqlite.org/optoverview.html
В рунете вообще не встречал обсуждений того, насколько хорош планировщик запросов эскулайт. Помнится, на форуме sql.ru Олег Бартунов на мой вопрос о возможности создания детерминированного планировщика для постгреса счел это невозможным. Хотя в эскулайте детерминированный планировщик практически полностью решает все проблемы с планами выполнения - в самых сложных случаях достаточно правильную статистику собрать/сгенерировать.
| | |
| |
| 5.38, Аноним (31), 12:38, 08/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Прочитаю, спасибо! Оптимизировать запросы пока нет необходимости, итак всё "летает". Таймауты ловятся редко и не парят совершенно. А WAL-режим разве работает при доступе к файлу по сети LAN? По-моему он только при чтении на той же машине работает.
| | |
| |
| 6.40, MBG (?), 08:45, 13/10/2019 [^] [^^] [^^^] [ответить]
| +/– |
Предпочтительнее простенький REST API сделать, чем сетевые файловые системы использовать. Или, как вариант, работать с копиями базы локально и время от времени синхронизировать с основной базой. Все зависит от задачи.
| | |
|
|
|
|
|
|
