The OpenNET Project / Index page

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



"Релиз СУБД SQLite 3.33"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз СУБД SQLite 3.33"  +/
Сообщение от opennews (ok), 15-Авг-20, 11:31 
Опубликован релиз SQLite 3.33.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53552

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Fracta1L (ok), 15-Авг-20, 11:31   +/
Как понять, в каких условиях/задачах не хватает сабжа и нужно переходить на тяжеловесов типа mysql и postgresql?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #8, #9, #17, #21, #22, #24, #68

2. Сообщение от Михрютка (ok), 15-Авг-20, 11:32   +1 +/
> Как понять, в каких условиях/задачах не хватает сабжа и нужно переходить на
> тяжеловесов типа mysql и postgresql?

когда расперделенные транзакции понадобятся

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #38

3. Сообщение от Аноним (11), 15-Авг-20, 11:32   –3 +/
>Максимальный размер БД увеличен до 281 TB.

Выглядит как искусственное ограничение. Это всего один-два десятка дисков, не серьёзно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

4. Сообщение от Иваня (?), 15-Авг-20, 11:39   –1 +/
Подскажите, где применяют binary64 числа, в каких кейсах?🧐
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #13, #72

5. Сообщение от A.Stahl (ok), 15-Авг-20, 11:55   +2 +/
switch (type)
case binary64: {

Вот в таких кейсах, например. А ещё этот кейс можно распечатать и положить в кожаный кейс. И в дермантиновый тоже. Вот.

P.S. РБЗ-127.2 §12, 13, 17 (а, б)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6, #10

6. Сообщение от Иваня (?), 15-Авг-20, 12:05   +/
Остряк. Я про то, в каких ситуациях лучше подходят такие числа?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #7, #84

7. Сообщение от A.Stahl (ok), 15-Авг-20, 12:11   +3 +/
Я не спец на самом деле, но здравый смысл подсказывает что такие числа полезны когда ты проводишь много арифметических операций с маленькими (уровня массы атома в килограммах) числами: при делении\умножении погрешность должна накапливаться довольно быстро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

8. Сообщение от Аноним (8), 15-Авг-20, 12:16   +1 +/
Склайт вроде как встроенная СУБД, если нужна клиент-серверность, когда разные приложухи стучат на один сервер БД, тогда уже её не хватит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11

9. Сообщение от Аноним (-), 15-Авг-20, 12:22   +4 +/
Когда останется пару свободных террабайтов, например при размере базы в 279 тб
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

10. Сообщение от funny.falcon (?), 15-Авг-20, 12:43   +1 +/
Что-то мне подсказывает, что binary64 в ieee754 - это привычный нам double, он же float64.

Видимо, в расширении до этого он обрабатывался на равне с другими, а тут они сделали special case и использовали нативные типы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15

11. Сообщение от Аноним (11), 15-Авг-20, 13:20   +/
Она по-моему плохо скалируется и работает в 1 поток (или что-то там такое), фактически можно иметь только 1 подключение к ней, иначе ты нарываешься на проблемы. Ну и ещё встроенных возможностей для серьёзного применения маловато, маловато. Я не помню подробностей, но когда рассматривали возможность мигрировать с mssql, она была одним из вариантов. Выбрали поcтгрес в итоге, всё норм, стало намного лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #12, #31, #41, #53

12. Сообщение от Здрасьте (?), 15-Авг-20, 13:59   +1 +/
c mssql на sqlite? ну вы затейники
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14

13. Сообщение от Здрасьте (?), 15-Авг-20, 14:01   +3 +/
Это обычный тип double
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #37

14. Сообщение от Аноним (11), 15-Авг-20, 14:23   –1 +/
Mssql тоже встраиваемая. Как и postgres.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18

15. Сообщение от Аноним (15), 15-Авг-20, 14:26   +/
А это не целоцисленный тип вроде (u)int64_t?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16

16. Сообщение от n00by (ok), 15-Авг-20, 14:55   +/
Дана же ссылка, где написано:

So-called "REAL" or floating point values are stored in the IEEE 754 Binary-64 format.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Alex (??), 15-Авг-20, 16:01   +4 +/
Чтение сразу несколькими клиентами работает отлично, но писать может только один клиент. Работа с датой - танец с бубном.
А в остальном отличная база, для многих локальных приложений хватает с головой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #29

18. Сообщение от Аномномномнимус (?), 15-Авг-20, 16:54   +2 +/
mssql ce с ограничением в 4Гб на базу и вечными поломками к счастью давно мертва. Про посгре - а давайте пруфы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #19

19. Сообщение от Аноним (11), 15-Авг-20, 16:58   +/
Я и не утверждал, что это было вчера. А вот постгре вполне и сегодня. https://www.postgresql.org/docs/current/ecpg.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

21. Сообщение от Анончик (?), 15-Авг-20, 17:22   +2 +/
Когда перестанете накидывать и начнёте работать так сразу поймёте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

22. Сообщение от proninyaroslavemail (ok), 15-Авг-20, 17:34   +1 +/
Хватает как БД для приложений. Как правило широко применяется в них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #27

24. Сообщение от Аноним (24), 15-Авг-20, 20:03   +1 +/
лайт - подходит только для монопольной работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

25. Сообщение от Аноним84701 (ok), 15-Авг-20, 20:19   +/
>>Максимальный размер БД увеличен до 281 TB.
> Выглядит как искусственное ограничение. Это всего один-два десятка дисков, не серьёзно.

С нетерпением ждем анонимных патчей.
https://www.sqlite.org/limits.html
> The maximum size of a database file is 4294967294 pages. At the maximum page size of 65536 bytes, this translates into a maximum database size of approximately 1.4e+14 bytes (281 terabytes, or 256 tebibytes, or 281474 gigabytes or 256,000 gibibytes).
>

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #52

26. Сообщение от Аноним (26), 15-Авг-20, 20:25   –1 +/
Embedded SQL это не встраиваемая СУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #28

27. Сообщение от Fracta1L (ok), 15-Авг-20, 20:27   +1 +/
То есть, если "одна БД - одна программа", то sqlite хватит более чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30, #71, #79

28. Сообщение от Аноним (11), 15-Авг-20, 20:46   +/
Ладно, я согласен, но ничто не мешает использовать её как встраиваемую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от Аноним (29), 15-Авг-20, 21:08   +/
> Чтение сразу несколькими клиентами работает отлично, но писать может только один клиент

Это, кстати, очень обманчивое заявление. В теории так и должно быть, но для этого нужно чтобы все соединения  всегда открывали базу только на чтение, и ни разу - на запись. Соединение, открытое только на чтение, не поддерживает WAL, а значит апгрейд во время транзакции невозможен (как и плавный апгрейд в принципе). Как следствие, открытие на чтение требует специальных танцев - это НЕ дефолтная конфигурация! В некоторых языках/фреймворках (например Django/python) открытие SQLite базы только на чтение вообще толком не работает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #45, #46

30. Сообщение от proninyaroslavemail (ok), 15-Авг-20, 21:42   +1 +/
Да. Для нужд хранения данных самой программы. Сложных БД там и не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

31. Сообщение от Аноним (31), 15-Авг-20, 21:59   +/
Пользуйся LMDB. Не SQL, но зачем лишние прослойки на локалхосте. Кстати, какой-то чувак как раз эту LMDB влепил бэкендом в SQLite c офигенным приростом производительности в итоге. Я не в теме что там у SQLite сейчас внутри, но для простых баз смысла в SQL не вижу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #32, #34

32. Сообщение от мяя (?), 15-Авг-20, 23:54   +/
Можно поподробнее? Это речь про это https://github.com/LMDB/sqlightning ?
Интересно как дела бы обстояли если бы там был более прокаченный вариант LMDB — MDBX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #33, #35, #36, #50, #57

33. Сообщение от мяя (?), 15-Авг-20, 23:58   +/
Хотя вот ещё нашёл: https://github.com/LumoSQL/LumoSQL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #58

34. Сообщение от Аноним (11), 16-Авг-20, 00:01   +/
На самом деле leveldb или rocks. Или даже kyoto cabinet. Если нужна запись. Да и жор у lmdb. Обойти sqlite не сложно. Но нет серебряной пули, в любом случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

35. Сообщение от мяя (?), 16-Авг-20, 00:09   +/
Ещё и такое: https://github.com/biokoda/actordb
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от Аноним (31), 16-Авг-20, 03:00   +/
Да, вроде оно.
ХЗ как бы там какие дела не обстояли, я юзаю LMDB и мне хватает и хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

37. Сообщение от Анонимус66 (?), 16-Авг-20, 05:10   +3 +/
Причем со всеми его недостатками в виде неточности машинной арифметики чисел двойной точности. Об этом они даже сами упомянули в документации https://www.sqlite.org/floatingpoint.html#decext
, а именно: "Floating point values are approximate ← Always remember this!" . Поэтому и набор функций там достаточно интересный идет к расширению.
Вообще, если они добавят расширение по умолчанию в amalgamation, то на всяких форумах тоже будут галдеть, почему при сложении двух различных чисел, получается лабуда, как в JS. Причем описанной проблемы из JS  https://olegbarabanov.ru/dev/problemy-bolshih-chisel-v-javas... , соответственно найдутся и те, кто не зная реализации, может удивиться и кричать, что Sqlite3 глючит и пр. Binary64 стоит применять с умом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #87

38. Сообщение от trolleybusemail (?), 16-Авг-20, 11:57   +3 +/
> расперделенные

Опечатка по Фрейду?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #49

39. Сообщение от Онаним (?), 16-Авг-20, 15:34   +/
> В режиме WAL (Write-Ahead Logging) в случае сбоя операции записи, ведущей к нарушению согласованности данных в файле shm, идущие следом транзакции теперь могут восстановить целостность файла shm

Um, кто-нибудь поясните мне, что тут написано.
Это особенность перевода, или UB теперь официально фича, а не баг?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40, #47

40. Сообщение от Онаним (?), 16-Авг-20, 15:36   –1 +/
Почитал про wal-index, да, это какое-это UB УГ, будьте осторожны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

41. Сообщение от economist (?), 16-Авг-20, 17:54   +/
Файловая SQLite - это 4 одновременных потока на чтения или 1 на запись. Если  кто знает как работает MS Access c 5-ю пользователями - то SQLite работает с такой же скоростью на выборку. Но запросы в ней пишутся в 2 раза быстрее и проще, и они кароч
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #42

42. Сообщение от economist (?), 16-Авг-20, 18:47   +/
А если вы любите язык С - то Python искаропки имеет модуль sqlite3 и по сути делает этот движок серверным, т.к. его WAL упорядочивает очередь. Сама по себе скорость SQLite настолько высока, что при 5-7 пользователях - файловая безсерверная база данных освобождается для следующей транзакции быстрее, чем MySQL, FireBird, PostgreSQL. Если это не одна и та же таблица и не одна и та же индексная сущность.
  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #43, #69, #86

43. Сообщение от Аноним (11), 16-Авг-20, 18:55   +/
Главное не пытаться что-нибудь записать в неё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #44

44. Сообщение от economist (?), 16-Авг-20, 21:24   +/
При записи будет таймаут, то есть ничего. Просто пауза для пишущего процесса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

45. Сообщение от economist (?), 16-Авг-20, 21:26   +/
Что за чушь!
Сначала хотел ведь написать подробно, но потом посмотрел на адресную строку и...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

46. Сообщение от economist (?), 16-Авг-20, 22:10   +/
Слушайте сюда, не надо домыслов про SQLite, пожалуйста. Это святая программа, величие которой - незыблемо.

Чтение файла в 4 потока (это файл, не порт и не сокет!) - доступно всегда и не зависит ни от чего, ни от вида ОС, ни от типа ФС, ни от "сервера БД", которого просто нет. Сделайте с 4-х хостов в сети SELECT * FROM TABLENAME - и все они отработают одновременно. Не делайте это с частотой 10 Гц, если ваша ОС + антивирус "не отпускают" файл быстрее чем за 1/10 секунды.

Для WAL (режим записи в журнал, чтобы уйти от 1 блокирующего потока на запись, делая его <=20 "поточым") - важно, чтобы это был файловый хост-процесс. Т.е. проводимый одной ОС. По сети WAL - не работает.

О том что соединение открыто на чтение - SQLite знает. Но сраnые оболочки, которые многие ставятне пойми откуда - могут открывать БД и на запись. Некоторые из них, всё-ж, полезны. Например, SQLite Manager (SM) - самое популярное в мире в 2016 году (3,5 млн загрузок) XUL-расширение для FireFox и ThunderBird - открывает SQLite всегда на запись, т.к. пишет (в неё же) - всю историю всех запросов, и дает среду для stored SQL. А также UDF функций на JS. И интерактивной сортировки. И Alter Table... - ну вы поняли. Это крутые функции, которые не умеют другие менеджеры БД, коих под сотню.

Дык вот, если кто-то работает с SQLite через SM - просто не мешайте им. SQLite так быстр, что блокировка сама пропадет за секунду.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #51, #70

47. Сообщение от economist (?), 16-Авг-20, 22:11   +/
Как раз все понятно.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #48

48. Сообщение от Онаним (?), 16-Авг-20, 22:14   –1 +/
> Как раз все понятно.

Вообще говоря никаких существенных "повреждений" файла СУБД, вызывающих ошибки у параллельно работающих приложений, не должно быть даже в случае краха приложения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #56

49. Сообщение от Аноним (49), 17-Авг-20, 17:33   +7 +/
Кровь, кишки, расперделенные транзакции
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

50. Сообщение от Аноним (50), 18-Авг-20, 10:01   +/
Лео, залогиньтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #54

51. Сообщение от Аноним (50), 18-Авг-20, 10:07   –1 +/
Самый лучший менеджер баз данных, какой я знаю, - это DBeaver. Бесплатное и свободное ПО. Переплюнул платный и проприетарный Navicat Premium.

Две вещи плохи.
1. автор взял и решил: "больше 32 бита я поддерживать не буду".
2. требует яву и сделан поверх eclipse, как следствие - страшно жрёт оперативу

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #59, #75

52. Сообщение от Аноним (50), 18-Авг-20, 10:09   +/
SQLite не принимает патчи. У них политика - "весь копирайт на весь код должен быть чисто нашим. Нужна фича в апстриме - вы нам о ней сообщаете, мы говорим, готовы ли мы держать такую фичу в апстриме, вы нам платите, мы её делаем."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

53. Сообщение от Убить_Криса (?), 18-Авг-20, 11:13   +/
неа, не в один, там зависит все от опций компиляции, MT короче она поддерживает на отличненько
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

54. Сообщение от мяя (?), 18-Авг-20, 16:10   +/
Я не лео, но идейку ему стоит подкинуть, хотя это наверное трудозатратно слишком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

56. Сообщение от пох. (?), 21-Авг-20, 16:52   +/
> Вообще говоря никаких существенных "повреждений" файла СУБД, вызывающих ошибки у параллельно
> работающих приложений, не должно быть даже в случае краха приложения.

"приложение" - это откуда-то из лексиона дефективных менеджеров.

В случае sqlite - "приложение" и есть сама субд. Разумеется, при крэше субд - с ее базами могут происходить всякие нежелательные чудеса. Пиши код чтоб не крэшился, что-ли, а то ж он не только базу попортит...

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

  

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #60, #61

57. Сообщение от пох. (?), 21-Авг-20, 17:04   –1 +/
> Можно поподробнее? Это речь про это https://github.com/LMDB/sqlightning ?

последнее обновление шесть лет назад, ага. очень важный и нужный проект.

> Интересно как дела бы обстояли если бы там был более прокаченный вариант
> LMDB — MDBX.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

58. Сообщение от пох. (?), 21-Авг-20, 17:06   –1 +/
> Хотя вот ещё нашёл: https://github.com/LumoSQL/LumoSQL

от это ты правильную весчь нашел - замах на мировую революцию, но начали (и, в основном, закончили) написанием CoC (что, конечно, очень важная и нужная задача, с учетом того что у автора оригинала там скорее anti-coc)

этот проект определенно имеет большое будущее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

59. Сообщение от пох. (?), 21-Авг-20, 17:08   –2 +/
> Самый лучший менеджер баз данных, какой я знаю, - это DBeaver. Бесплатное
> и свободное ПО. Переплюнул платный и проприетарный Navicat Premium.
> Две вещи плохи.

бггг - это одна и та же вещь

> 1. автор взял и решил: "больше 32 бита я поддерживать не буду".

именно потому, что:
> 2. требует яву и сделан поверх eclipse, как следствие - страшно жрёт
> оперативу

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

60. Сообщение от Онаним (?), 22-Авг-20, 09:29   +/
> "приложение" - это откуда-то из лексиона дефективных менеджеров.

Внезапно - просто дословный перевод слова "application".

> В случае sqlite - "приложение" и есть сама субд.

Нет. Есть код приложения, и есть библиотека СУБД. Приложение не работает напрямую с файлами СУБД, оно работает с СУБД только через API данной библиотеки. Забота о файлах - задача данной библиотеки.

> Пиши код чтоб не крэшился, что-ли, а то ж он не только базу попортит...

Но вы-то наверняка способны заранее предсказать весь +INF возможных ситуаций, включая собственные ошибки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #62

61. Сообщение от Онаним (?), 22-Авг-20, 09:31   +/
И даже ладно, не собственные ошибки, а кривые руки вон того васяна, который одну из цгруп своего докерка запилил на 128M RAM, что постоянно валит приложение в OOM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #63

62. Сообщение от пох. (?), 22-Авг-20, 09:53   –1 +/
> Внезапно - просто дословный перевод слова "application".

ну так это - для дЭффективных слово-то.

У технического персонала есть программы.

> Нет. Есть код приложения, и есть библиотека СУБД.

код "приложения" состоит из "библиотек" (sqlite необязательо и незачем, кстати, быть оформленной именно "библиотекой" в смысле ld), и что?

С момета включения ее в код - ты и есть "субд". С какими-то еще фичами.
В этом ключевое отличие embedded database.

> Но вы-то наверняка способны заранее предсказать весь +INF возможных ситуаций, включая
> собственные ошибки.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

63. Сообщение от пох. (?), 22-Авг-20, 10:25   –1 +/
Ну и чем тебя тут спасла бы самая золотая субд?
Давай орацкл запустим кривыми руками того же васяна, а потом, глядя на неустранимые ora006, будем всем рассказывать, какой орацл плохой. Или попробуем поднять рухнувший postgres (вот кто умеет крэшнуться сам по себе с оригинальными последствиями), или вон могу подарить снапшот mysql в принципе не подлежащий восстановлению не смотря на lock database в момент снапшота.

embedded db не позволяет тебе изолировать критичную часть "приложения" там где к ней нет доступа у васянов ни в плане администрежа, ни в плане гуанокодинга? Ну да, тоже мне, открытие.

Ну меня это как-то не беспокоит, я десять лет с такими имел дело на заре карьеры - начиная от уродов типа dbase и заканчивая вполне приличным clarion (да, они все embedded, правда, своеобразным способом). Ничуть не сложнее и не неудобнее чем орацл - скорее наоборот, ибо предсказуемее. Бэкап при этом никто не отменял.

В конце-концов, в XXI веке все еще кое-где у нас порой не абсолютно все на свете хранится в таблицах - как тебе твоя крэшащаяся программа например в обработке денег смотрится?
Или даже банально твоей почты - когда потеряет письмо от твоего нигерийского дяди, завещавшего три миллиарда не нигерийских долларов первому, кто на него ответит? (Ну ок, от работодателя с предложением интересной работы в хороших условиях - не получив ответа, ставящего галочку "соискатель не имеет нужной квалификации чтобы хотя бы почту читать")

При этом, повторяю, именно sqlite имеет максимум средств для восстановления в этой ситуации, васянами не воспроизводимых на коленке - о чем я каждый раз получаю напоминание, перезапуская фуфлофокс. Эти дятлы неосилили sqlite, ага, они умеют ведь кодить только в "html+js" и еще вот немножечко в md. Поэтому то что их предшественники хранили в ней, у них перенесено в нескучный json. Без средств сохранения целостности, восстановления и хотя бы проверки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #64

64. Сообщение от Онаним (?), 22-Авг-20, 10:33   +/
Золотая субд не нужна, но вот наличие странного поведения (скажем так, UB) в обработке файлов напрягает.
Хотя лично мне пофиг, я в таком режиме SQLite3 не использую, жертвую производительностью немножко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #65

65. Сообщение от пох. (?), 22-Авг-20, 10:57   –1 +/
> Золотая субд не нужна, но вот наличие странного поведения (скажем так, UB) в обработке файлов

там нет никакого странного поведения.
> напрягает.

а в случае орацла ты спишь спокойно, потому что просто ничего не знаешь о том, как у него устроен лог.
Ну ооок...

> Хотя лично мне пофиг, я в таком режиме SQLite3 не использую, жертвую производительностью
> немножко.

переписывание файла с данными на каждую транзакцию - это не так чтоб немножко, в общем-то.

И от потери транзакции на 100% не гарантирует.

Если тебе так уж остро необходима дополнительная защита от гунанокодеров - возможно, стоит рассмотреть архитектуру с изолированными frontend/backend - причем, в рамках модных современных концепций, между ними не обязательно гонять sql, сейчас модно понакрутить поверх еще три слоя абстракций, особенно в вебне.
В принципе, я даже знаю целую одну программу, в которой это могло бы спасти безнадежное дело (zabbix, ага - но поздно)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #66, #67, #73, #82

66. Сообщение от Онаним (?), 22-Авг-20, 13:25   +/
Орацл я имел счастье одному товарищу выковыривать с полумёртвой системы и полумёртвого диска.
Другому товарищу имел счастье выковыривать InnoDB в MySQL в такой же ситуации, и без первичного неймспейса.
Имел я этот оракл )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #74

67. Сообщение от Онаним (?), 22-Авг-20, 13:26   +/
Потеря транзакции - терпимо. Вот отказы в исполнении соседних транзакций - так себе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

68. Сообщение от РедХет (?), 24-Авг-20, 19:00   +/
Очевидно, когда появится необходимость в многопользовательской работе с более-менее сложными сценариями изоляции транзакций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

69. Сообщение от РедХет (?), 24-Авг-20, 19:02   +/
А как СHKP отрабатываются? Есть ли они вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

70. Сообщение от РедХет (?), 24-Авг-20, 19:04   +/
Нет. Лайт как был "встройкой" для однопользовательских задач, так ей и остался. Прочие применения -- явная девиация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

71. Сообщение от РедХет (?), 24-Авг-20, 19:07   +/
От характера "программы" зависит. Лайт не MVCC и не умеют делать настоящий Serializable или RR. Поэтому, если искажения прецеденции недопустимы или нужно честное RR, то Лайт не подойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

72. Сообщение от РедХет (?), 24-Авг-20, 19:10   +/
Когда делаешь операции на числах с плавающей запятой или принимает такие числа из оборудования. Вообще, когда с 754-тым работаешь. А это, например, приём данных от прецезионного измерительного оборудования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

73. Сообщение от РедХет (?), 24-Авг-20, 19:15   +/
А вы знаете как "лог" у Оракла устроен? Если вам это спать не даёт, то вряд ли знаете. У Оракл журнал повторного исполения непрошибаем вообще. В принципе. Вот у Слона пока ещё не убрали настройки, которые позволяют убить файлы данных даже при нормально работающем WAL-е. Но они не по умолчанию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

74. Сообщение от РедХет (?), 24-Авг-20, 19:18   +/
Что-то мне подсказывает, что максимальный ваш опыт это вытаскивание капустной кочерыги из горлышка мутного пузыря.
У Инно вектора отмеры в журнал не пишутся. О чём разрабы честно пишут. И это при определённых условиях может стать причиной краха при внезапной остановке. У Оракла -- пишутся. Оракл вообще крайне сложно угробить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #76, #77

75. Сообщение от РедХет (?), 24-Авг-20, 19:21   +/
Да ничего он не жрёт. Обычная IDE. Минусы у неё, на мой взгляд, другие. Меня, например, бесит, что нельзя транзакциями явно управлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

76. Сообщение от Онаним (?), 24-Авг-20, 19:25   +/
Оракл - наше всё!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #80

77. Сообщение от Онаним (?), 24-Авг-20, 19:26   +/
А вообще почитали бы про redo и undo логи, что-ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #78

78. Сообщение от РедХет (?), 25-Авг-20, 11:19   +/
Какие ещё redo- и undo-"логи"? В Оракле в журнал повторного исполнения пишутся и вектора отмены, и вектора повторного исполнения. Нет там никаких редо и анду-логов. Есть сегменты отмены. Изменения в них формируются после того, как вектор отмены (но не сами данные отмены) попал в журнал повторного исполнения.
В Сиквеле -- не так. В Сиквеле в "журнал транзакций" (который никакой не журнал транзакций, а журнал изменений) пишутся именно данные отмены, а не вектора отмены.
И в Слоне иначе. Там "журнал транзакций" хранил только записи вектор отмены и полные копии страниц сразу после CHKP, а векторов отмены просто нет -- они там не нужны из-за особенностей реализации MVCC, где отмена хранится в виде замогиленных удалённых данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #81

79. Сообщение от РедХет (?), 25-Авг-20, 11:22   +/
Лайт нужен тогда, когда вы хотите просто получить возможность работать с данными через SQL. Потому что это очень удобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

80. Сообщение от РедХет (?), 25-Авг-20, 11:23   +/
Ну, в общем-то, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

81. Сообщение от РедХет (?), 25-Авг-20, 11:27   +/
Да, тут описался:"И в Слоне иначе. Там "журнал транзакций" хранил только записи вектор отмены". Слон хранит в журнале вектора (и данные тоже) повторного исполнения, вектора отмены не хранит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

82. Сообщение от РедХет (?), 25-Авг-20, 11:43   +/
Ой, можно подумать вы знаете как у "оракла устроен лог".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

83. Сообщение от РедХет (?), 25-Авг-20, 11:44   +/
А как лайт исходно работал без поддержки 754-того? Он же, вроде как, встройка для военных исходно. А там 754-тый используется.
Ответить | Правка | Наверх | Cообщить модератору

84. Сообщение от НямНямка (?), 25-Авг-20, 17:18   +/
Например, когда у тебя есть технические ограничения на размер регистра, а данные, которые в этом регистре предполагается хранить меняются в очень широком диапазоне. Какой-нибудь сейсмодатчик или спектрофотометр. Тогда их рациональней хранить в виде числа с плавающей запятой. А коль исходные данные хранятся в виде числа с плавающей запятой, то и принимающая система должна такие данные уметь забрать без потерь точности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

85. Сообщение от НямНямка (?), 25-Авг-20, 17:21   +/
Э, вряд ли. 754-тый типично применяется, когда у величины нет натурального штучного выражения. Вернее, когда им можно в рамках данного предметного домена принебречь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

86. Сообщение от НямНямка (?), 28-Авг-20, 17:26   +/
А вы точно себе представляете, что такое WAL?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

87. Сообщение от РедХет (?), 29-Авг-20, 18:29   +/
О ужас. Вообще не все вещественные числа представимы степенью двойки. Принципиально. И что, теперь компы -- на свалку, а двухметровые логарифмические линейки -- наше всё?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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