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

"Релиз СУБД PostgreSQL 14"	+/–
Сообщение от opennews (?), 30-Сен-21, 19:58
После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 14.  Обновления для новой ветки будут выходить в течение пяти лет до ноября 2026 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55891
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от menangen (?), 30-Сен-21, 19:58	+11 +/–
Пора переводить прод с мускула на постгрю!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #47, #125

2. Сообщение от InuYasha (??), 30-Сен-21, 20:01	+5 +/–
Слоник - это вещь! Моё уважение проекту.
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Аноним (89), 30-Сен-21, 20:02	+/–
Надеюсь до постгри раст не доберется!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #105

6. Сообщение от Аноним (6), 30-Сен-21, 20:11	–5 +/–
А было бы неплохо, повышение качества еще никому не вредило
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #7, #11, #96, #146

7. Сообщение от Аноним (7), 30-Сен-21, 20:24	–1 +/–
Переписывание затянется в бесконечность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

8. Сообщение от кукурузка (?), 30-Сен-21, 20:40	+4 +/–
> Если ваш "прот" можно вот так взять и перевести с MySQL на PostgreSQL, то это вызывает подозрение, что ваш "прот" - это сонник. А у этот комеент вызывает подозрения что вы не вкурсе как писать переносимые и расширяемые приложения и завязываетесь всегда на специфичные фишки всего вокруг. И это вызывает сильные подозрения что созданное вами пригодно для использования.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #28, #40, #60, #71, #77, #135

9. Сообщение от кукурузка (?), 30-Сен-21, 20:41	+2 +/–
Отличный проект. Успехов.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Аноним (10), 30-Сен-21, 20:52	–2 +/–
Бредовый синтаксис. У них всегда были с этим проблемы и вот опять.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64, #76

11. Сообщение от Аноним (11), 30-Сен-21, 20:56	+4 +/–
Посмотрите сколько пунктов в стандарте MISRA. Память лишь один пункт из многих. А понты из закорючек в одну строчку наоборот нежелательно. Для Раста есть подобный стандарт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12, #14

12. Сообщение от Аноним (12), 30-Сен-21, 21:04	+1 +/–
Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #17, #52

13. Сообщение от Аноним (13), 30-Сен-21, 21:21	+/–
Уже обновился на Убунте. Теперь еще численные типы могут содержать значение Infinity.
Ответить | Правка | Наверх | Cообщить модератору

14. Сообщение от Анонн (?), 30-Сен-21, 21:31	+1 +/–
Посмотрите внимательней на требования MISRA и список тех, кто этой MISR'е следует. Даже ядро линя, а оно существенно более критично чем постгресс, ему не соответствует. А вы про прикладной софт...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #69

15. Сообщение от Аноним (17), 30-Сен-21, 21:31	–6 +/–
Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53, #63

16. Сообщение от Аноним (16), 30-Сен-21, 21:33	+11 +/–
Хм, тут как спросишь, какую СУБД выбрать в проект, так сразу начинается - "смотря какие задачи". А сейчас вдруг оказывается, что не надо фишки под задачи подбирать, пишите "переносимые".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #25, #45, #22, #26, #27, #61

17. Сообщение от Аноним (17), 30-Сен-21, 21:33	–2 +/–
Зато на Расте синтаксис подталкивает к тому чтобы писать говнокод. А говнокод можно переписывать бесконечно. Это же рай для тех кто любит все переписывать бесконечно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

19. Сообщение от kissmyass (?), 30-Сен-21, 21:49	–1 +/–
зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

22. Сообщение от 2021 (?), 30-Сен-21, 22:05	+10 +/–
Мамкиным понторезам не лень 2k21 вместо 2021 набирать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

25. Сообщение от Аноним (25), 30-Сен-21, 22:17	+2 +/–
У товарища просто примитивный бэкенд и задачи. Соответственно там и отличий никаких нет. И нагрузка соответствующая. Конечно у всех БД свой SQL несовместимый SQL. Перевести базу данных очень сложно. Надо обмазываться тестами на SQL запросы и их производительностью. Такого, конечно, никто не делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #32, #48

26. Сообщение от Аноним (16), 30-Сен-21, 22:17	–2 +/–
Папкиным манторезам не лень 2021 вместо 2021 набирать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

27. Сообщение от Аноним (25), 30-Сен-21, 22:19	+/–
Ну они сейчас достаточно быстрые. На прошлом проекте в базу никто практически ни лез. Там даже кастомных индексов за запросы не было. Производительности хватало. И для многих проектов хватает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

28. Сообщение от kai3341 (ok), 30-Сен-21, 22:33	+/–
> завязываетесь всегда на специфичные фишки всего вокруг Падаван явно мал и глуп У разных реализаций разный синтаксис. То, что в Oracle зовётся decode, в sap hana именуется map. Разный синтаксис преобразования типов, и так далее. Так вот, всё это мелочи, полностью нивелируемые ORM. Дальше чуть поинтереснее. Есть сущность sequence -- простейший счётчик. Так вот, в sqlite секвенсов нет и судя по тому, как автор др*чит на автоинкременты, в ближайшей перспективе не появится. В Машу и Мускуль секвенсы завезли "на днях" -- наконец-то как у взрослых дядей сделали. Дальше ещё прикольнее. Оказывается, что разные реализации по-разному реализуют MVCC. Постгря гадит под ноги, что потом героически вычищает autovacuum. InnoDB, как и Oracle, имеет rollback и redo сегменты, и в обоих применяется кластерный индекс. Эти различия приводят к различным стоимостям операций CRUD. Например, rollback в postgres практически бесплатный, но заставит вас страдать в InnoDB и Oracle. Update в постгресе всегда создаёт новую строку в таблице, и частые обновления заставят вас страдать. Кластерный индекс позволяет найти запись за O(1) (ну почти, там есть нюансы) , что особенно прикольно на большом числе JOIN. Всё это заставляет реализовывать логику приложения по-разному. Расскажешь, как нивелировать эти различия?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #31, #49, #167

29. Сообщение от One More Аноним (?), 30-Сен-21, 22:36	+2 +/–
>> Повышена эффективность работы индексов B-tree и решена проблема с разрастанием индексов при частом обновлении таблиц. finally
Ответить | Правка | Наверх | Cообщить модератору

31. Сообщение от kissmyass (?), 30-Сен-21, 22:48	–2 +/–
вместо счетчика использовать свой генератор айдишек базирующийся на времени (или рандомный типа GUID, если первичный ключ может быть не кластерным, так называемый Heap, привет SQL Server), про многоуровневые JOINы забудь, особенно в нагруженных СУБД или при шардинге (да и не нужны они вообще, разве что для пейджинга с сортировкой на стороне СУБД), кластерный индекс и некластерный имеют всегда O(n), зависит от размера таблицы и балансировки дерева, разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс, а потом саму запись, данные не находятся вместе с индексом, но один хрен это все O(n) и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #36

32. Сообщение от пох. (?), 30-Сен-21, 23:05	–2 +/–
Делают, почему же не делают.  Только делают там где понимают, нахрена ж страдать. Ну например мы тут перешли с оракла на... оракл, ага. 19й. Ну пару раз в опу дали... и немного пришлось отсо...ть с производительностью в некоторых узкоспециальных местах. Куды деваться, немодные версии снимают с поддержки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

33. Сообщение от пох. (?), 30-Сен-21, 23:06	–1 +/–
vacuum full надеюсь наконец-то запретили и объявили окончательно и бесповоротно deprecated? А, нет, померещилось...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

34. Сообщение от й (?), 30-Сен-21, 23:17	+5 +/–
нооо мооой прооот! свитый из багов и снов всем моим бедам назло вовсе не так уж плох
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #139

35. Сообщение от PetrG (ok), 30-Сен-21, 23:22	–1 +/–
Нужное. Разрешаю дальнейшую разработку. А то тут некоторые повадились ненужное без разрешения кодить...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #147, #166

36. Сообщение от kai3341 (ok), 30-Сен-21, 23:28	–2 +/–
> вместо счетчика ... GUID Очень умная идея. Привет, фрагментация кластерного индекса и всей таблицы, развлекуха с пагинацией и прочие весёлости > про многоуровневые JOINы забудь, особенно в нагруженных СУБД Прикольно. А что взамен? Через N+1 делать? > кластерный индекс и некластерный имеют всегда O(n) Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс > разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс > данные не находятся вместе с индексом, но один хрен это все O(n) Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи > и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры Как вьюха или хранимая процедура решает проблему неизбежного создания новой записи при операции UPDATE в постгресе? Как вьюха или хранимая процедура позволяют обойти проблему дорогого ROLLBACK в InnoDB или Oracle?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #41

37. Сообщение от Аноним (37), 30-Сен-21, 23:29	+/–
Ещё никто не спрашивал про пакеты и undo?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #81

38. Сообщение от Ilya Indigo (ok), 01-Окт-21, 00:06	–2 +/–
> В новых установках по умолчанию обеспечено применение парольной аутентификации с использованием метода SCRAM-SHA-256 вместо md5 (параметр "password_encryption" при генерации postgresql.conf теперь устанавливается в значение 'scram-sha-256'). Ну наконец-то каждый раз при установке не придётся это ручками изменять, ждал этого давно.
Ответить | Правка | Наверх | Cообщить модератору

39. Сообщение от Ilya Indigo (ok), 01-Окт-21, 00:09	–3 +/–
> SELECT * FROM test WHERE details['attributes']['size'] = '"medium"' А чем старый не устроил? SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #57, #127

40. Сообщение от Аноним (40), 01-Окт-21, 00:09	–4 +/–
Все нормальные люди используют orm а не пишут sql запросы и кот полностью переносимый А потом оно начинает тормозить и пишут запросы которые выполняться быстро но...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #68

41. Сообщение от kissmyass (?), 01-Окт-21, 00:44	+2 +/–
вот не надо из контекста выдергивать, я дословно написал: "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс > Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) > Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи что там взаимоисклющающего? кластерный индекс хранится вместе со строкой и задает порядок физического следования строк в таблице (поэтому он и должен быть последовательным во избежании проблем с перфомансом), а если индекс не кластерный, то он не хранится с данными и никак не определяет порядок следования строк в самой таблице не кластерному индексу нужно прочитать свои данные на диске, и только потом по полученному указателю надо найти физическое расположение данных, это всего лишь плюс 1 дисковая операция, но асимптотическая сложность для обоих индексов будет одинакова, именно поэтому она и называется асимптотической. если тебе надо еще подробнее, то это не ко мне, я считаю, что я уже и так с тобой задержался... и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца "покровительственный" тон!? очнись парень, ты обосpался...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46

45. Сообщение от Умпа (?), 01-Окт-21, 02:01	–3 +/–
>> "смотря какие задачи" Смотря КАКАЯ ЛИЦЕНЗИЯ!!! 300% местных далба обов пишет для собственной бабушки, по ходу. За иороженку. И, да! -- мой код работает _И_ под MySQL, _И_ под MS SQL, _И_ под Oracle. Окощько открыл мана в преференциях мана, указала мана база мана и мана окей нажимала. А постгресс -- МИТ. Поэтому он.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #84

46. Сообщение от kai3341 (ok), 01-Окт-21, 03:19	–2 +/–
> "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", А, ну это точно решает проблему с пагинацией (нет) > если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс Как это решает проблему фрагментации самого индекса? > O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) Или используй О-нотацию правильно, или не используй вообще. "Ой ладно придираться, не O(N), а O(log N)" Разница между 4294967296 и 32 не имеет значения? > кластерный индекс хранится вместе со строкой Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) > и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца > "покровительственный" тон!? очнись парень, ты обосpался... То есть по БД больше нечего сказать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #56, #59, #130

47. Сообщение от Аноним (48), 01-Окт-21, 03:27	+/–
Пора тебе побеспокоиться за свой тыл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

48. Сообщение от Аноним (48), 01-Окт-21, 03:29	+/–
У тебя похоже вообще задач нет, одни смузи на уме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

49. Сообщение от Аноним (48), 01-Окт-21, 03:32	+1 +/–
Обсмеялсо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

50. Сообщение от Аноним (50), 01-Окт-21, 04:40	+1 +/–
А смысл?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

51. Сообщение от Аноним (50), 01-Окт-21, 04:42	–2 +/–
Фронтендеры пугаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #72

52. Сообщение от leap42 (ok), 01-Окт-21, 05:38	–1 +/–
> Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - значит безопасно. Миллионы растоманов не могут ошибаться. Mozilla, помню, говорила обратное🤔
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

53. Сообщение от leap42 (ok), 01-Окт-21, 05:40	+2 +/–
> Мастер-Мастер подвезли? Нет? Тогда сразу в гарбедж. лол, зочем? он же ничего кроме боли не дает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

55. Сообщение от Аноним (55), 01-Окт-21, 06:58	+/–
Я, если честно, вообще не знаю, зачем до сих пор нужен SQL, если в него приходится пихать все больше и больше фишек обычных языков. Давайте уже оставим SQL в покое, но встроим в него какую-нибудь Джаву, чтобы прямо в запрос скрипт всовывать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58, #79, #85, #136

56. Сообщение от aa (?), 01-Окт-21, 07:03	+2 +/–
> А, ну это точно решает проблему с пагинацией (нет) а вы пагинацию делаете по первичному ключу? пользователь обычно хочет сортировку по чему-то более полезному, названию например, или цене. Зачем вобще первичный ключ при пагинации юзать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

57. Сообщение от Фёдор (?), 01-Окт-21, 07:05	+1 +/–
Более читабельный. Это уже наркомания какая-то: SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #65, #73, #112, #148

58. Сообщение от m (??), 01-Окт-21, 07:09	+2 +/–
Уже есть встроенные языки plsql, perl, ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #66, #74

59. Сообщение от Bx (ok), 01-Окт-21, 07:16	+2 +/–
> Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) Ого, а можно поподробнее? Про нигде не хранится. И как с nullable, delete и прочей малозначимой херней типа сжатия быть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

60. Сообщение от mos87 (ok), 01-Окт-21, 07:58	+1 +/–
если ты думаешь, что в риал ворлде (с)(тм) кто-то настолько заморачивается, что в одном проекте пишет скуль запросы сразу под разные ДБ (хотя всегда сидят на 1й одновременно), то ты либо 1) не знаешь о чем говоришь 2) не работаешь с запросами сложнее SELECT a_couple_of_columns FROM one_single_table
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #150

61. Сообщение от Счетовод (?), 01-Окт-21, 08:01	+/–
2k21 == 2210 != 2021
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

63. Сообщение от mos87 (ok), 01-Окт-21, 08:17	+2 +/–
тебе твой мастер не нравится? слишком белый?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #92

64. Сообщение от mos87 (ok), 01-Окт-21, 08:19	–3 +/–
почему этот нереально жырный и унылый троллинг не удаляется? троллботнумшаблон не заходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

65. Сообщение от mos87 (ok), 01-Окт-21, 08:21	+/–
пихать в скуль вот это всё - это и есть наркомания скуль придуман для относительно простеньких декларативненьких запросиков. ими и должен заниматься. попытка запихать вселенную в скуль приводит к тому, что у отвёртки из авторемнабора вдруг ручка в виде руля - потому что у машины тоже руль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #78

66. Сообщение от mos87 (ok), 01-Окт-21, 08:24	+/–
да, это просто традиция что ДБшники как секта всё пихают в свою СУБД и ограничены только её возможностями. раньше СУБД были как отдельная ОС, теперь же и нормальные обычные приложения (на том же Перл или простихоспаде жабе) работают с БД не хуже, благо библиотеки/обвязки нынчо достаточно развиты. если что-то зело специфическое и аццки оптимизированное надо, тогда да. Но 90%ам это не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #80

68. Сообщение от Аноним (68), 01-Окт-21, 08:59	+3 +/–
Все нормальные люди используют комбинацию подходов: используют ORM и Query Builders для банальных запросов, и пишут SQL там, где это требуется из соображений производительности. Универсальные ORM/QB хороши для рутинных вещей, но не способны сгенерировать оптимальные запросы и использовать специфику конкретной РСУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #91, #94

69. Сообщение от Аноним (69), 01-Окт-21, 09:17	–2 +/–
> Даже ядро... не соответствует Это хорошо или плохо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #88

70. Сообщение от pofigist (?), 01-Окт-21, 09:43	+/–
Зачем все это в SQL DB?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #113, #126

71. Сообщение от letsmac (ok), 01-Окт-21, 09:45	+2 +/–
Ну если у тебя SQL это тупой Store без хранимых процедур и ты слово профайлер слышишь в первый раз - то тогда да, это не проблема. Купи побольше процов в облаке и всё работать будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

72. Сообщение от Ilya Indigo (ok), 01-Окт-21, 10:26	+1 +/–
> Фронтендеры пугаются. Что фронтендеры вообще в SQL-е забыли, с ним работают только бекеры?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #111

73. Сообщение от Ilya Indigo (ok), 01-Окт-21, 10:28	+/–
> Более читабельный. > Это уже наркомания какая-то: > SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium' Особенно невозможность разименовать json(b) в которой нужно оборачивать сравниваемую строку в двойные кавычки. который является символом экранирования в pqsql. Офигенно читаемо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

74. Сообщение от Alex (??), 01-Окт-21, 10:57	+1 +/–
Мне это не нужно,я этого не понимаю. Значит никто не понимает и никому этотне нужно! Дураки какие-то деньги тратят на разработку никому ненужных вещей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

75. Сообщение от лютый жабби__ (?), 01-Окт-21, 11:04	–3 +/–
>  SELECT ('{ "postgres": { "release": 14 }}'::jsonb)['postgres']['release']; о мама мия... почему эти люди не могут посмотреть как сделано у нормальных людей? у монги апи уже 5 лет назад было разрывающе удобнее подобного бреда....
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #114

76. Сообщение от лютый жабби__ (?), 01-Окт-21, 11:08	–2 +/–
>Бредовый синтаксис. У них всегда были с этим проблемы и вот опять. у постгреса похоже в штате больше форумных ботов, чем прогеров. :) иначе я просто не понимаю откуда  столько минусов у любой критики слонопотамов. сам пользовался слоном много лет назад, но не понимаю как можно остаться на постгресе хотябы 1 раз пощупав монго ) как жигуль vs нормальная япошка )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #110

77. Сообщение от Наме (?), 01-Окт-21, 11:10	+/–
Это ваше "переносимое и расширяемое", если ему пофиг на транзакционное ядро, которое под ним лежит, скорее всего никакие СУБД вообще не использует. ИСАМ и реляционные БД с полноценным WAL-ом и MVCC это абсолютно разные вселенные. Если ИСАМ был выбран осознанно, то переводить его на реляционные схемы c MVCC нет никакого смысла -- будет просто тупо медленней и в разы более толсто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

78. Сообщение от Наме (?), 01-Окт-21, 11:16	+2 +/–
Декларативные не равно простенькие. Коррелированные подзапросы с окнами и свёртками сложно назвать простенькими. При этом они крайне немногословны относительно императивных реализаций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #141

79. Сообщение от Наме (?), 01-Окт-21, 11:18	+/–
Потому что в Сиквеле двумя фразами можно сделать то, что на императивных языках делается тысячами строк всяких библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

80. Сообщение от Наме (?), 01-Окт-21, 11:24	+1 +/–
У СУБД свои задачи, у фронтэнда и контроллеров -- свои. Манипулировать данными в десятки раз проще на Сиквеле, а обрабатывать всякие приведения форматов удобнее другими инструментами. ОРМ в реальных применениях годны только для самых простейших вызовов. И не потому, что делают плохие запросы, а потому, что нет ни одного массового императивного языка, у которого была бы транзакционная модель памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #142

81. Сообщение от Наме (?), 01-Окт-21, 11:29	+/–
Подобие пакетов есть. Подобие анду-сегментов тоже есть. Но больше похоже на версионное хранилище МС Сиквела, чем на Оракловую реализацию. Да и не сильно надо, вообще-то. Вот вам анду зачем? Для чего-то вроде флэшбэка по анду?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

82. Сообщение от МояВенда (ok), 01-Окт-21, 11:42	–4 +/–
После добавления в монгодб транзакций, постгрес стал официально не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

84. Сообщение от Steve Ballmer (?), 01-Окт-21, 11:51	+1 +/–
Там наверное select password from wp_users where username = 'vasya'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #89, #124, #128, #131

85. Сообщение от nobody (??), 01-Окт-21, 11:56	+/–
Оракуль пытался, ещё с 90-х. Чё-т не очень жаба SQL или хотя бы PL/SQL заменила
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #86

86. Сообщение от Наме (?), 01-Окт-21, 12:04	+/–
Сиквел ничем не заменить. ПЛ хорошо подружен с Сиквелом. А Ява -- она не для замены ни того, ни другого. Просто на ней можно делать то, что на ПЛ делать затруднительно или реализация получается жутковатая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

87. Сообщение от Наме (?), 01-Окт-21, 12:05	+3 +/–
Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #99, #101, #107

88. Сообщение от Анонн (?), 01-Окт-21, 12:10	+2 +/–
С точки зрения надежности - плохо. Но есть мнения что ядро какое оно сейчас вообще невозможно написать с такими ограничениями. Как минимум пришлось бы заставить всех драйверописателей и остальных, чей код тянется в ядро, следовать этим ограничениям. А это нереально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

89. Сообщение от Аноним (89), 01-Окт-21, 12:10	+1 +/–
А тебя не обламывает раскладку переключать ради забивания"k"? Ты тратишь впустую свое время и совершаешь лишнее движение. Всякое лишнее движение не нужно, так как порождает хаос и тратит еще больше твоего времени в итоге. Лучше бы это время на что-то более полезное потратил. А так из закономерностей и секунды складываются в минуты/часы/дни/годы. Подобрал бы лучше кокой-нить мэйлпайл да пилил годный проект для хомо мыл. Ах да, так коммерционализация такая себе. Да. Поэтому ты лучше буш тут кочевряжится с написанием дат смайликами сношающихся поней, но делом не займешься. Пячалька.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

91. Сообщение от kai3341 (ok), 01-Окт-21, 12:21	–2 +/–
> и пишут SQL там, где это требуется из соображений производительности Открой для себя SQLAlchemy. Эта ORM позволяет извлечь как все преимущества императивного подхода, разбив ORM-запрос на модули и вынеся подзапросы отдельно, так при этом сохранить все преимущества SQL -- ты волен написать любой валидный запрос (почти. Не без косяков. Но они устранимы)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #93, #104, #109, #137

92. Сообщение от Аноним (92), 01-Окт-21, 12:28	+/–
Ему тройничок подавай
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

93. Сообщение от Наме (?), 01-Окт-21, 12:29	+/–
А как там rollbacks-ы отрабатывают? Вот налепил ты объектов, решил их транзакционно поменять, поменял и тут -- хлоп -- в самом конце какое-то исключение вылезло. Как твоя Алхимия такую ситуацию обрабатывает? Состояние объектов откатит, как было до начала транзакции? А?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #118, #138

94. Сообщение от Наме (?), 01-Окт-21, 12:30	+/–
Сейчас, в общем-то, не важно как составлен запрос, если он логически корректен. С ОРМами другие проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #121

96. Сообщение от An (??), 01-Окт-21, 12:38	+2 +/–
В этом проекте на С с качеством все в порядке. Давайте не портить его. rust уже влез в linux. Неплохо бы сначала посмотреть, что из этого получится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

97. Сообщение от Аноним12345 (?), 01-Окт-21, 12:47	+1 +/–
Респект
Ответить | Правка | Наверх | Cообщить модератору

99. Сообщение от Аноним (99), 01-Окт-21, 13:19	+2 +/–
Я аш смузи подавился. Вы все врёте!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

101. Сообщение от МояВенда (ok), 01-Окт-21, 13:59	–1 +/–
С сайта монги: "MongoDB 5.0 is the latest generation of the database most wanted by developers". Это называется давно умер? MOST WANTED, Карл! Starting in version 4.0, MongoDB provides the ability to perform multi-document transactions against replica sets. Хоть сам и сижу на постгре, но рассматриваю ее исключительно как легаси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #103, #106, #115

103. Сообщение от пох. (?), 01-Окт-21, 14:04	+2 +/–
На сарае еще и не такое написано, но там - дрова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

104. Сообщение от 3 (?), 01-Окт-21, 14:20	+/–
внезапно, мир не ограничен петоном. и даже в мире питона этих орм штук 10, например джанговское, peewee и тд. из чего следует, что алхимия не универсально-могуча.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #120

105. Сообщение от Аноним (105), 01-Окт-21, 15:01	–2 +/–
чо за постгри?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

106. Сообщение от Аноним (105), 01-Окт-21, 15:02	+1 +/–
чо за постгре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

107. Сообщение от лютый жабби__ (?), 01-Окт-21, 16:16	–3 +/–
>Монго давно умер. И нет там никаких "транзакций" и быть не может в принципе. глупый слонопотамщик не понимает, что в монге данные немного по другому хранятся и по существу там были "транзакции" всегда, т.к. в монге не нужно атомарно редактировать по несколько размазанных на несколько таблиц строк ) т.е. атомарность это КОСТЫЛЬ реляционных субд, а не мегафича!  ) ну а сейчас и транзакции давно есть, с 4.0 кажись
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #116

108. Сообщение от Аноним (108), 01-Окт-21, 16:36	+2 +/–
Дело не в твоём времени, а в том что твой текст выглядит плохо, неприятно читать.
Ответить | Правка | Наверх | Cообщить модератору

109. Сообщение от Аноним (108), 01-Окт-21, 16:40	+/–
SQLAlchemy прекрасный ORM, один из лучших среди всех языков. Но даже на нём написать запрос на пару экранов это будет мучение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #119

110. Сообщение от Аноним (108), 01-Окт-21, 16:43	–1 +/–
> я просто не понимаю Может быть проблема в тебе, что если ты не прав, не приходило такое в голову?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #132

111. Сообщение от Аноним (108), 01-Окт-21, 16:48	–1 +/–
Javascript теперь и на беке давно :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

112. Сообщение от Аноним (108), 01-Окт-21, 16:51	+/–
У этих операторов разный тип результата (-> json, ->> text), а у оператора индексации массива способа поменять тип кроме оборачивания в CAST нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

113. Сообщение от Аноним (108), 01-Окт-21, 16:52	+/–
Для функциональности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #164

114. Сообщение от Аноним (108), 01-Окт-21, 16:58	–2 +/–
API на javascript? Как вы себе представляете добавление javascript в SQL?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #133

115. Сообщение от Аноним (108), 01-Окт-21, 17:00	+/–
Афира почитайте, а то может оказаться что транзакции не совсем транзакционны как сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

116. Сообщение от Аноним (108), 01-Окт-21, 17:05	+2 +/–
https://aphyr.com/tags/mongodb Транзакции не имеют никакого отношения к тому как физически хранятся данные, это логическая конструкция и атомарность записи объекта в файл не является достаточной для реализации всех уровней изоляции транзакций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #117, #134

117. Сообщение от МояВенда (ok), 01-Окт-21, 17:38	+/–
Причем тут вообще файлы? Монго гарантирует атомарность на уровне документа (или нескольких документов если использовать транзакцию). Физическая реализация может быть какой угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

118. Сообщение от kai3341 (ok), 01-Окт-21, 18:10	+/–
Отрабатывает. Только я избегаю использовать ActiveRecord
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

119. Сообщение от kai3341 (ok), 01-Окт-21, 18:11	+/–
Писал запросы на пару экранов. Не испытал мучения, а наоборот, писал с удовольствием. Как я сказал ранее, алхимия позволяет получить все преимущества императивного подхода (модульность, переиспользование кода и интроспекцию), не потеряв при этом преимуществ сырого SQL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

120. Сообщение от kai3341 (ok), 01-Окт-21, 18:13	+/–
Количество != качество. С джангой сравнил. Сравнил бы в knex -- был бы другой разговор
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

121. Сообщение от kai3341 (ok), 01-Окт-21, 18:18	+/–
Как раз важно. Есть 100500 способов составить запрос, получив на выходе один и тот же набор данных, но с различными стратегиями вычитывания данных. Производительность может различаться в разы. Например, SQL позволяет поместить подзапрос не только в `FROM`, но и в `SELECT`. Стратегия извлечения данных будет сильно разной
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #149

122. Сообщение от iZEN (ok), 01-Окт-21, 19:11	–3 +/–
Чем PostgresQL 14.0 лучше Firebird 4.0?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #123

123. Сообщение от Alladin (?), 01-Окт-21, 20:06	+/–
Версия больше) Ну але гараж, что за вопросы странные... Чем гугл лучше яндекса и давай отвечай сразу в одном сообщении.. кто так делает..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #145

124. Сообщение от мимокро (?), 01-Окт-21, 20:21	+/–
лавров.jpg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

125. Сообщение от FSA (??), 01-Окт-21, 20:43	+1 +/–
> Пора переводить прод с мускула на постгрю! Не стоит. Но стоит задуматься о создании нового прода уже на PostgreSQL. Я не особый спец. Любитель. Но приятно было отказаться от MySQL. Сначала привыкаешь к особенностям. Потом учишься делать хитрые запросы. Потом балуешься с json, которые участвуют в индексах. Потом понимаешь, что для того, чтобы сделать то, что позволяет PostgreSQL на MySQL, мягко говоря, сложно. Но если ты просто меняешь БД в настройках своей CMS - то это не миграция, а херня. Не стоит. Твой код должен быть написан именно для PostgreSQL с учётом его особенностей. Код не может быть заточен и под MySQL и PostgreSQL. Это компромисс для эникейщиков, чтобы поставить систему на любой сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

126. Сообщение от Яхз (?), 01-Окт-21, 23:41	+/–
Чтобы не таскать данные между базой и чем-то ещё по сети туда-сюда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

127. Сообщение от edo (ok), 02-Окт-21, 00:08	+1 +/–
> SELECT * FROM test WHERE details->'attributes'->>'size' = 'medium' Мне интересно, как эта наркомания вообще пролезла в когда-то человекочитаемый sql '["a", "b", "c"]'::jsonb ?& array['a', 'b'] '{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

128. Сообщение от Аноним (128), 02-Окт-21, 01:37	+/–
2k во всём мире значит 2000. И это правильно! Двадцать с лишним лет назад умный человек создал оригинальное сокращение при описании проблемы двухтысячного года. (Ну и плюс Windows 2k). Оно экономит целых 2 (два!) символа при написании и является совершенно правильным. Третье  десятилетие это сокращение не даёт покоя пытливым и ищущим умам. 2k3, 2k8 от этих новаторов ещё можно как-то объяснить - экономия целого символа, плевать, что с потерей смысла. Но 2к21 ничего не экономит, т.е. смысла не имеет, кроме оригинальничанья, кривляния, тролинга. Это примерно как 2км8 или 2кг5 - вот сколько это в позиционной системе счисления? А то, что в автозамену поставил - молодец, целеустремлённый. И немного напоминает то, что в последнее время веб-макаки делают с программированием и с языками в частности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

130. Сообщение от edo (ok), 02-Окт-21, 06:21	+/–
> Если строка занимает > 123 байта, а значение первичного ключа 42, то расположение записи вычисляется > элементарно, и к самой записи мы переходим за O(1) И как оно вычисляется? Значение первичного ключа не равно номеру строки (и вообще может не быть числом).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

131. Сообщение от ptr128 (?), 02-Окт-21, 07:23	+1 +/–
Сопротивление среднего резистора 2002 Ом или все же 2200 Ом? https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRtqmzN... А у этого резистора сопротивление, по Вашему, 33 Ом. Или все же 330? https://sesaga.ru/wp-content/uploads/2012/05/rasshifrovka.jpg Разделитель "K" нужно употреблять все же понимая, что он обозначает, а не от балды. 2021 = 2K021, а 2K21 = 2210
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

132. Сообщение от лютый жабби__ (?), 02-Окт-21, 07:41	+1 +/–
>Может быть проблема в тебе не думаю. в могучем слоне всё так же - если на диске занято больше 60% то vacuum full уже не сделать? )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

133. Сообщение от лютый жабби__ (?), 02-Окт-21, 07:43	+/–
>SQL это какое-то гомно из 70-х прошлого века? Зачем за него цепляться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #151

134. Сообщение от лютый жабби__ (?), 02-Окт-21, 07:47	–2 +/–
>Транзакции не имеют никакого отношения к тому как физически хранятся данные Транзакции в 99% случаев не нужны. Либо нужны, но тормозят больше чем нужно...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #152, #159

135. Сообщение от ptr128 (?), 02-Окт-21, 07:49	+/–
> завязываетесь всегда на специфичные фишки А варианты? Хотите приведу целый ряд запросов, которые вообще без изменений легко выполняются и в MS SQL и в PostgreSQL, но во втором без модификации уходят в глухой table scan? Обзор тут: https://www.endpoint.com/blog/2020/06/postgresql-improve-gro.../ Я уже молчу о временных и, тем более, глобальных временных таблицах. Тут уже в каждой СУБД свои заморочки, требующие при миграции, нередко, просто переписывания кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

136. Сообщение от ptr128 (?), 02-Окт-21, 07:54	+/–
Java давно есть https://github.com/tada/pljava Но заменить SQL она все равно не в состоянии. Парадигма другая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

137. Сообщение от Аноним (68), 02-Окт-21, 10:18	+/–
SQLAlchemy прекрасна. Но ее прекрасность обусловлена особенностями Питона, на другом языке такую же красоту не сделать. Можно попробовать изобразить что-то подобное на Kotlin с его DSL, но вряд ли у меня дойдут руки :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

138. Сообщение от Аноним (68), 02-Окт-21, 10:20	+/–
Не надо лепить объекты по принципу ActiveRecord для проектов сложнее бложика с комментариями. Надо использовать Data Mapper и принцип Aggregate Root из DDD. А роллбэки там даже распределенные есть, там отличный transaction manager.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

139. Сообщение от Док (?), 02-Окт-21, 12:19	–1 +/–
Оо подошли старперские оптимизации бесконтактного боя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

140. Сообщение от Док (?), 02-Окт-21, 12:25	+/–
Наверное хорошая штука но ставить не буду никогда тк ее разрабы судя по документации ненавидят заранее всех кто будет ее использовать и всех кто хочет найти примеры)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #143

141. Сообщение от mos87 (ok), 02-Окт-21, 12:26	+/–
само собой, ибо вся мякотка скрыта в СУБД но они и обычно в хвосте переносимости и самое главное обычно запросы содержащие такое не ограничиваются и малым размером. а это уже всяко плохо. неуправляемо, неподдерживаемо. если 5 строчный запрос с окном - это неплохо. horses for courses.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

142. Сообщение от mos87 (ok), 02-Окт-21, 12:42	+1 +/–
да, но бизлогика на скуле - это неуправляемая mess я лично за то чтобы сырые данные с мин обработки хранить в иерархическом виде, а то что нужно крутить, сравнивать, перекрёстно-линковать - это в таблички, где этому и место.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

143. Сообщение от Аноним (-), 02-Окт-21, 13:35	+2 +/–
Очень странный довод. По мне, так у них просто замечательно вылизанная документация - у всех бы так было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #154

144. Сообщение от ыы (?), 02-Окт-21, 19:42	+/–
а когда уже нормальный active/active кластер завезут?
Ответить | Правка | Наверх | Cообщить модератору

145. Сообщение от ыы (?), 02-Окт-21, 19:58	+/–
Не лучше а хуже... И ответ на этот вопрос вы узнаете сразу же как американский сегмент отключат от интернета...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #153

146. Сообщение от Alladin (?), 03-Окт-21, 00:05	+/–
Все давно придумано за вас. И да, есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

147. Сообщение от Alladin (?), 03-Окт-21, 00:06	+/–
Зачем спрашивать у вас разрешение, вы кто дядя?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #165

148. Сообщение от Alladin (?), 03-Окт-21, 00:07	+/–
Почему же, +- как в php.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

149. Сообщение от Прохожий (??), 03-Окт-21, 05:12	+1 +/–
Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #161

150. Сообщение от Прохожий (??), 03-Окт-21, 05:17	+/–
Возьмём, например, 1С. Несколько мне известно, их продукт работает в реальном мире под разными СУБД, и там запросы сложнее, чем вы написали. Я работаю в компании, которая разрабатывает продукты (сложные и большие) под разные СУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #158

151. Сообщение от Прохожий (??), 03-Окт-21, 05:39	+/–
Да будет тебе известно, что это из 70-х снабжается математическим аппаратом и вообще стройной теорией обработки данных. Где вы такие "прогрессивные" только беретесь-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

152. Сообщение от Прохожий (??), 03-Окт-21, 05:44	+1 +/–
Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только. Не поймут твой "прогрессивный" подход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #160, #162

153. Сообщение от Прохожий (??), 03-Окт-21, 05:55	+/–
Вы хотели сказать "российский". С чего бы американцам отключаться от Интернета. Они подобной фигнёй (изоляционизмом) не страдают. Да и вообще, вон, есть российская контора, которая пилит свою редакцию PostgreSQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #156

154. Сообщение от Прохожий (??), 03-Окт-21, 05:58	+/–
Довольно хреновая у них документация. Архитектура, например, вообще нигде не описана. Приходится с миру по нитке скрести. Да и многие особенности работы тоже нигде не упоминаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #157

155. Сообщение от Прохожий (??), 03-Окт-21, 06:00	+/–
А когда уже direct io, undo нормальный завезут.
Ответить | Правка | Наверх | Cообщить модератору

156. Сообщение от ыы (?), 03-Окт-21, 10:21	+/–
Есть такой список, "страны угрожающие американскому образу жизни". Это часть доктрины национальной безопасности США. И с каждым годом этот список все все шире... А после строительства Северного Потока- он станет еще шире... С этими странами американские компании не могут торговать, вести отношения... Так что не исключена ситуация когда США самоизолируется от всего мира... ну кроме ее сателлитов :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #171

157. Сообщение от ыы (?), 03-Окт-21, 10:37	+1 +/–
Так исходный код же есть... Мало? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

158. Сообщение от mos87 (ok), 03-Окт-21, 10:51	+/–
Насколько мне известно там постгрес. но вполне может статься что бывает и разное. скорее всего может. только в одной конторе для одного проекта никто не будет расписывать запросы с учетом разницы между СУБД такой запрос выглядит сложным: SELECT col1||col2 FROM table ? вроде нет. Однако он может давать совершенно разные результаты на Oracle и сабже, а на других вовсе вызовет ошибку синтаксиса. ты вот сейчас серьёзно сказал, что люди для себя для своих проектов (или для клиентов, там обычно *всё равно подразумевается что СУБД известна и незаменяема*) сидя на одной СУБД будут писать этот запрос так: SELECT НЕКАКАЯ_ФУНКЦИЯ_ОПРЕДЕЛЯЮЩАЯ_ВЫПОЛНЯЮЩУЮ_СУБД( есди_оракл то col1||col2, если_пг COALESCE( col1, 0 )||COALESCE( col2, '0' ), если_мускль CONCANT( col1, col2 ), если_голимый col1+col2 ) FROM table
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #168

159. Сообщение от ыы (?), 03-Окт-21, 11:50	+/–
А вы уверены что транзакций там нет? Может вам просто предоставляют механизм неких гарантий, а под капотом там неявно вызываемые автоматические транзакции как раз и работают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

160. Сообщение от ыы (?), 03-Окт-21, 11:51	+/–
Ну почему каком-нибудь... Скорее всего в Сбербанке.. Он под себя подомнет весь ИТ в Россиии... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

161. Сообщение от kai3341 (ok), 03-Окт-21, 15:53	+/–
> Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан. Святая наивность. Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`. Главный оптимизатор запроса находится перед компом. Оптимизатор БД же тупенький конечный автомат, способный только предварительно вычислить константы, определить мощность множества (cardinality) и выбрать подходящий индекс (или неиспользование индекса -- бывает, так выгоднее).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #169

162. Сообщение от лютый жабби__ (?), 03-Окт-21, 18:51	–2 +/–
>Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только А ты не ляпни про постгрес на собеседовании в банке ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #163

163. Сообщение от ыы (?), 03-Окт-21, 19:17	+/–
Иногда стоит промолчать а не демонстрировать уровень своей компетентности https://www.cnews.ru/news/top/2021-03-23_podderzhivat_za_250...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

164. Сообщение от pofigist (?), 03-Окт-21, 19:37	+/–
Какое отношение имт все эти свистгперделки к функционалу SQL DB?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

165. Сообщение от petrg (ok), 03-Окт-21, 22:30	–1 +/–
Q.E.D. Хочу opennet но для взрослых. За*был этот десткий сад в комментариях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

166. Сообщение от petrg (ok), 03-Окт-21, 22:31	+/–
А по моему хорошая шутка получилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

167. Сообщение от Наме (?), 04-Окт-21, 10:20	+/–
Мягко скажем, винегрет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

168. Сообщение от Прохожий (??), 05-Окт-21, 20:20	+/–
Смотреть в сторону ORB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #170

169. Сообщение от Прохожий (??), 05-Окт-21, 20:29	+/–
> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #173

170. Сообщение от mos87 (ok), 05-Окт-21, 20:32	+/–
зачем? (и что это?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #172

171. Сообщение от Прохожий (??), 05-Окт-21, 20:32	+/–
Пока из таких стран - Россия, Китай и КНДР, насколько мне известно. Но, может, я чего не знаю, дополняйте список.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

172. Сообщение от Прохожий (??), 05-Окт-21, 20:37	+/–
Object Relational Bridge. Зачем смотреть? Есть у вас сложный продукт, который однако, легко разбиваются на модули. Можете целиком продавать все модули (крупным денежным клиентам) вместе с Oracle. А можете отдельные модульки с PostgreSQL мелким небогатым. В итоге у вас более полный охват рынка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

173. Сообщение от kai3341 (ok), 05-Окт-21, 21:56	+/–
>> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> > Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? FYI: стаж != экспертиза > Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Как бы да. Когда сам знаешь, где разбросаны грабли, ты их обходишь. Как я говорил, основной оптимизатор SQL-запроса этот запрос пишет. А оптимизаторы ошибаются. И иногда не просто ошибаются, а даже обсираются. Оптимизаторы очень не любят большое число JOIN на одном уровне -- Oracle не шмог в похожет случае. Кстати, основная причина промаха оптимизатора -- некорректная оценка мощности множества. > Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Вот отсюда подробнее. Где они там машинное обучение всунули, и, главное, зачем. Предоставьте пруфы. > Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. Ну вообще да, в 99% случаев они неплохо справляются, если самому на грабли не наступать. > А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения. Я не говорю о том, что оптимизатор не может вообще ничего. И я согласен, оптимизаторы становятся всё умнее (или менее глупыми. Была ржака как-то -- в оптимизаторе MySQL нашли место, где rvalue не вычислялся на момент анализа запроса, хотя все данные для этого были). Оптимизаторы действительно творят невозможное. Помнится, запрос по временному ряду был очень весело ограничен: `WHERE TRUNC(event_created, 'MM') = :event_month` -- так вот, оптимизатор тут таки шмог, и вместо ожидаемого TABLE FULL ACCESS внезапно был INDEX RANGE SCAN. Да, он вычитал занные за весь год, но это сильно лучше полного чтения таблицы. Но ещё раз -- оптимизатор -- это программа, она не может ничего "выдумать". Задача оптимизатора -- сократить число чтений. Принятие же решения по сути является задачей поиска минимума. Он способен перебрать ограниченное число вариантов -- не больше, чем в него заложил программист. Оптимизатор, каким бы "умным" он ни был, останется тупеньким конечным автоматом. И очень странно, что я об этом рассказываю человеку, у которого "20 лет стажа работы с СУБД"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

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

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