The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года , opennews (?), 04-Янв-24, (0) [смотреть все]

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


76. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/–
Сообщение от Аноньимъ (ok), 04-Янв-24, 20:32 
> с большинством данных они справляются примерно одинаково

С вами я могу только солглашаться. Всегда интересно послушать мнение профессиорнала.

> Если, конечно, структуру нормальный инженер проектировал.

Абсолютно с вами согласен.

> Странные ваши суждения

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

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

Для меня БД - всегда была вспомогательным интрументом. Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.
Когда-то давно работал немного с Ораклом и МС(в рамках дотнета), но для себя быстро перешёл на мускл и теперь Марию. Оно просто работает сразу, в моём опыте. Причём отлично, удалось избежать новомодных timeseries баз. Сжатие страниц? то-же работает отлично, для моих нужд самое оно. По моему в PG аналогичного механизма нет?

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

83. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/–
Сообщение от Аноним (26), 04-Янв-24, 21:22 
> Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.

Весьма наглядная иллюстрация тезиса

> Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.

Причем, в отсутствие особых требований этот путь может быть нулевым, так как постгрес очень неплохо работает с настройками по умолчанию.

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

93. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +2 +/–
Сообщение от fuggy (ok), 04-Янв-24, 23:57 
PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL. Лучше поддержка разных типов данных JSON, массивов, енумов. Больше типов индексов, есть частичные, функциональные, индексы для геометрических типов данных. Продвинутое управление ролями, даже есть row level security. Так что плюсы в использовании PostgreSQL есть.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

97. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +1 +/–
Сообщение от Аноним (180), 05-Янв-24, 00:14 
Ну ок, повысим до php-шника за $8/час
Ответить | Правка | Наверх | Cообщить модератору

108. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +1 +/–
Сообщение от Аноним (108), 05-Янв-24, 05:50 
Все эти плюшки нужны только если тащите логику приложения в слой хранения данных.
Обычно принято дублировать логику. То есть она и в базе, и в приложении. Зачем этот БДСМ нужен, каждый ответит для себя сам.
У кого-то это способ защиты от написанного джунами кода, у кого-то одержимость контролем всего и вся.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

147. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +1 +/–
Сообщение от fuggy (ok), 05-Янв-24, 15:07 
Да, а потом будем тянуть тысячи строк в браузер, чтобы по новой изобрести алгоритмы сортировки и джойнов. Не всегда с базой работает только одно приложение. Ещё есть тестировщики и разработчики, которые могут напрямую в бд вставить что-то. И что в каждое приложение добавлять логику ограничений, проверки уникальности, внешние ключи. Есть схема данных и зачем это тащить в логику приложения. Разгребать потом дубликаты и искать проблемы где забыли добавить внешние ключи намного сложнее, чем мнимый выигрыш от того что бд будет работать быстрее, если мы не будем использовать внешние ключи.
Ответить | Правка | Наверх | Cообщить модератору

173. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/–
Сообщение от Аноним (180), 05-Янв-24, 19:47 
В слое хранения могут быть только данные, а не логика. Логика же это код, выполняемый рядом с данными. И здесь речь идёт не о типах данных и прочих похожих фичах, а о UDF-ках. Нужны они по совершенно очевидной причине: перелопачивание данных прямо в СУБД работает быстрее аналогичной логике на строне клиента (на клиент нужно туда-сюда гонять данные). Этот подход широко используется в биг дате в виде map-reduce и прочих схемах распределённых вычислений. Для OLTP от этого тоже может быть польза на некоторых схемах баз.

Сами же дополнительные типы данных и индексы тоже помогают ускорять работу. Обычно дублирования логики не делают т.к. завязка на фичи PG больше никуда не переносима и на другой СУБД уже не получится  получить такие же ТТХ эмуляцией логики.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

126. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  –1 +/–
Сообщение от Аноньимъ (ok), 05-Янв-24, 11:43 
> Лучше поддержка разных типов данных JSON

Это зло.

> PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL.

Разверните.

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

https://mariadb.com/kb/en/geographic-geometric-features/

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

148. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/–
Сообщение от fuggy (ok), 05-Янв-24, 15:40 
>JSON

К сожалению это жизнь и JSON проник везде. И иногда проще вставить JSON, чем создавать таблицу на 20 колонок в которую будем раскладывать на колонки, и потом собирать в одни объект обратно. Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.

>check constraint
>Prior to MySQL 8.0.16, CREATE TABLE permits only the following limited version of table CHECK constraint syntax, which is parsed and ignored:
>Before MariaDB 10.2.1 constraint expressions were accepted in the syntax but ignored.

До каких-то версий, синтаксис поддерживался, но по факту ничего не происходило. Разве можно такой СУБД пользоваться, которая так легкомысленно к стандарту относится. Деление на ноль даёт NULL. Ещё позволяет указывать в SELECT колонки которых нет в GROUP BY или агрегатные функции. С одной стороны может удобно, с другой может выдать значение из любой строки.

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

150. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/–
Сообщение от Аноньимъ (ok), 05-Янв-24, 16:03 
Не знаю, можно или нельзя. Я не большой сторонник стандартов ради стандартов. И не знаю насколько им следует например МС или Оракл.

Вообще с этим жсоном наверное моя главная проблема в том, что табличная СУБД пытается зачем-то быть объектной, там ещё и графовые движки есть.

Хотя и гонять жейсон по сети в базу и обратно видится идеей довольно странной.
Но это я так, модные молодёжные BD вообще по http работают.

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

154. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +2 +/–
Сообщение от fuggy (ok), 05-Янв-24, 17:20 
Вообще-то PostgreSQL разрабатывался как объектно-реляционная, не путать с документной, а не просто реляционная. Там можно определять пользовательские типы данных, например валютный тип, где сумма и код валюты лежат в одной колонке, чтобы работать атомарно, и определять функции над новыми типами. Графовым чаще всего нужен свой язык, так как SQL плохо подходит.
Я тоже согласен что молодёжным базам работать по текстовому протоколу, вместо бинарного это менее производительно. Это ж для каждой строки нужно все заголовки колонок передавать, очень неэффективно.
Ответить | Правка | Наверх | Cообщить модератору

177. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/–
Сообщение от Аноним (180), 05-Янв-24, 20:12 
> Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.

Здесь принцип деления совершенно другой: в БД может быть форматная обязательная часть данных и неформатная в виде документа. Раньше были отдельные СУБД для форматных данных с чёткой схемой и специальные документные СУБД. Поле JSON в PG существует для объединения этих двух подходов  в реляционной СУБД. Таким образов в колонки по прежнему уходят форматные данные, а документ в JSON. Раньше документ приходилось хранить в виде блоба и декодировать только на клиенте. C JSON можно строить индексты по документам и работать с ним прямо из SQL. Вот и вся магия с JSON полем. Хранить обычные колонки в JSON поле не эффективно.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

187. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/–
Сообщение от fuggy (ok), 05-Янв-24, 23:35 
> C JSON можно строить индексты по документам и работать с ним прямо из SQL

Я про JSON и веду речь. Можно создать индекс, но подход немного в другом. Что если нужно построить индекс по json-колонке, то скорее всего нужно селектить и джойнить, то тогда эффективней вынести её в отдельную настоящую колонку (конечно если у вас микро таблица). А если уж нужно апдейтить json-поле, то тогда это делать почти обязательно, ведь PostgreSQL пока не умеет редактировать на месте и будет копировать, например мегабайтный json, целиком. Если нужно просто: юзер json положил, юзер json целиком прочитал, то jsonb идеально подходит. На заголовки строки и колонки есть накладные расходы, и если колонок много и их не обрабатывают на SQL, то можно замерять и в некоторых случаях может оказаться что их эффективнее хранить виде jsonb. Но в коменте выше было именно иметь в виду атомарный json-объект.

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

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

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




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

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