Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17   вперед  Ctrl
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Это не более чем часть общего процесса постепенной замены Oracle на нормальные СУБД.

Вы искренне полагаете, что PostgreSQL - это нормальная СУБД? Я Вас уверяю, когда в 9-й версии oracle mysql докрутят работу с внешними ключами и триггерами - использование этой академической поделки (постгрес) резко начнет падать. Даже если ребята из Постгрес Про включатся активнее в работу над новыми "фичами". Если движок изначально кривой - это уже ничем не подправить. Увы.
26 дек 18, 17:24    [21774053]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10019
Andy_OLAP
когда в 9-й версии oracle mysql докрутят работу с внешними ключами и триггерами


а докрутят ли? У меня сложилось впечатление что языком хранимых процедур и триггеров они не хотят заниматься. С 5-й версии ничего
существенного так и не было сделано. Типа используйте в качестве тупого хранилища и норм, остальное ORM сделает.
26 дек 18, 17:34    [21774066]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Симонов Денис
С 5-й версии ничего существенного так и не было сделано. Типа используйте в качестве тупого хранилища и норм, остальное ORM сделает.

Вы шутите???

Выражения DDL стали атомарными и защищенными от падений, метаданные в транзакционной таблице, плюс "SQL Window functions" и CTE, плюс Descending Indexes, плюс "Добавили Resource Group". Это помимо прочих приятных мелочей.
26 дек 18, 17:38    [21774072]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Симонов Денис,

Из комментариев к данной статье - "И, для полноты картины, в MariaDB CTE и оконные функции есть уже год. REGEXP_REPLACE, SQL-роли и гистограммы — четыре года. Но вот атомарных DDL, например, нет пока" и "а еще check constraint есть. зато в марии json фейковый. и чем дальше, тем больше они (эти две субд) будут отличаться".

Так что осталось check constraint и foreign keys плюс триггеры полноценно прикрутить. И можно в любой production в сборке от percona. Там Света Зайцева грудью встанет, но не пропустит кривой релиз.
26 дек 18, 17:40    [21774074]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Andy_OLAP
PgSQLanonymous3
Это не более чем часть общего процесса постепенной замены Oracle на нормальные СУБД.

Вы искренне полагаете, что PostgreSQL - это нормальная СУБД? Я Вас уверяю, когда в 9-й версии oracle mysql докрутят работу с внешними ключами и триггерами - использование этой академической поделки (постгрес) резко начнет падать. Даже если ребята из Постгрес Про включатся активнее в работу над новыми "фичами". Если движок изначально кривой - это уже ничем не подправить. Увы.


они там хоть Констрейнты починили в этом mysql?
26 дек 18, 17:40    [21774075]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Симонов Денис,

И если у Вас 5-я версия - обратите особое внимание на "Для меня самое главное в innodb таблицах наконец-то сохраняется значение максимального авто-инкремента даже при удалении записей или перезагрузках базы
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id из-за чего было много не уловимых багов".
26 дек 18, 17:41    [21774077]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Озверин
Andy_OLAP
пропущено...

Вы искренне полагаете, что PostgreSQL - это нормальная СУБД? Я Вас уверяю, когда в 9-й версии oracle mysql докрутят работу с внешними ключами и триггерами - использование этой академической поделки (постгрес) резко начнет падать. Даже если ребята из Постгрес Про включатся активнее в работу над новыми "фичами". Если движок изначально кривой - это уже ничем не подправить. Увы.


они там хоть Констрейнты починили в этом mysql?

Еще нет. Наличие нескольких разных движков вносит определенные сложности в данный процесс.

Вот кошерный доклад Алексея Копылова.
[youtube=]
26 дек 18, 17:43    [21774079]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10019
Andy_OLAP,

какое отношение CTE и оконные функции имеют к языку хранимых процедур?
Я только рад что они наконец сделали язык SQL более или менее вменяемым. Но именно по части триггеров ХП и функций особо ничего не сделано.
26 дек 18, 18:09    [21774109]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
Вы искренне полагаете, что PostgreSQL - это нормальная СУБД?

Естественно.

Andy_OLAP
Я Вас уверяю, когда в 9-й версии oracle mysql докрутят работу с внешними ключами и триггерами - использование этой академической поделки (постгрес) резко начнет падать.

Это Вам Ларри по телефону рассказал? Как и про TCP-E? ;)
Впрочем, поживём --- увидим.

Andy_OLAP
Даже если ребята из Постгрес Про включатся активнее в работу над новыми "фичами".

Ах ну да, они же основная движущая сила разработки PostgreSQL. ;)

Andy_OLAP
Если движок изначально кривой - это уже ничем не подправить. Увы.

Правильно, вот потому-то использование Oracle и падает. ;)
26 дек 18, 18:32    [21774137]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Andy_OLAP, таки о каком mysql может идти речь, если то, что субд должно делать судб - не работает? Лучше уж медленная и большая постгря с агрессивным автовакуумом, чем подели типа mysql.
26 дек 18, 21:54    [21774296]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
miksoft
Member

Откуда:
Сообщений: 37748
Andy_OLAP
при удалении записей или перезагрузках базы
И.
Если удалить последнюю запись (или откатить ее вставку) и рестартовать базу, то счетчик пересчитается.
https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html
To initialize an auto-increment counter after a server restart, InnoDB executes the equivalent of the following statement on the first insert into a table containing an AUTO_INCREMENT column.

SELECT MAX(ai_col) FROM table_name FOR UPDATE;
InnoDB increments the value retrieved by the statement and assigns it to the column and to the auto-increment counter for the table.


Andy_OLAP
А то до этого как не старайся настроить, всё равно в разреженной таблице база пыталась писать по уже существующим id
Единственный вариант сделать такое, который я встречал (в т.ч. на подфоруме по MySQL за много лет) - руками вставить запись с id за пределами текущего автоинкремента.
26 дек 18, 22:10    [21774312]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Озверин
Andy_OLAP, таки о каком mysql может идти речь, если то, что субд должно делать судб - не работает?

Если бы не работало - тогда бы LAMP (Linux + Apache + MySQL + PHP) не стал бы стандартом де-факто. Впрочем, Вы это и без меня знаете.
27 дек 18, 13:07    [21774678]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 750
MySQL, ИМХО занимает нишу решений начального, редко среднего уровня. Мне гораздо больше нравится Firebird и её форки в этой нише. Postgres - средне-тяжелые решения, где MySQL делать нечего.
В принципе, вся его популярность - наследие Web 1.0, где от него кроме быстрого чтения не требовалось. Ни транзакций долгое время не было, ни языка ХП и триггеров. Так, упрощенный движок. Вот с этого нижайшего старта он и прется в коммерческую сферу.
Postgre и фаер с самого начала делались как полноценные коммерческие сервера. Разного калибра. Зато все четко по делу.

MySQL перегружен всякой бессмысленной мотней типа десятка движков, особенностей, кривым синтаксисом...
27 дек 18, 13:23    [21774702]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Andy_OLAP
Озверин
Andy_OLAP, таки о каком mysql может идти речь, если то, что субд должно делать судб - не работает?

Если бы не работало - тогда бы LAMP (Linux + Apache + MySQL + PHP) не стал бы стандартом де-факто. Впрочем, Вы это и без меня знаете.



ответ в стиле: если бы postgresql была настолько плохой, как вы говорите, то ее не было б в каждом первом стартапе.

Как такое вообще можно представить? https://dev.mysql.com/doc/refman/5.7/en/create-table.html

mysql.com
CHECK

The CHECK clause is parsed but ignored by all storage engines. See Section 1.8.2.3, “Foreign Key Differences”.
27 дек 18, 13:27    [21774711]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Озверин,

Это вдумчиво выбранный стиль "если написано по стандарту SQL, но не реализовано - не ломаться и делать без явной выдачи ошибки". Там, где другая СУБД выругается и откажется - mysql сделает то, что внутри уже реализовано, пропустив то, что еще не реализовано. Это позволяет делать мультиплатформенный код и переносить НА mysql решения, которым не нужен check constraints например. Да, решение принимаете лично Вы, но переделывать ничего не придется с точки зрения кода.

И это осознанный выбор такого стиля. Что касается подключаемости движков - таки огромный плюс. Замена ISAM на приличные InnoDB или XtraDB это кошерно.
27 дек 18, 13:34    [21774714]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48414

Andy_OLAP
Там, где другая СУБД выругается и откажется - mysql сделает то, что внутри уже
реализовано, пропустив то, что еще не реализовано. Это позволяет делать
мультиплатформенный код и переносить НА mysql решения, которым не нужен check constraints
например.

Это было бы прелестно, но тогда почему он до сих пор использует обратные апострофы в
delimited identifiers и ругается на стандартные кавычки вместо "молчаливого пропускания"?..

Posted via ActualForum NNTP Server 1.5

27 дек 18, 14:14    [21774767]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Andy_OLAP
Озверин,

Это вдумчиво выбранный стиль "если написано по стандарту SQL, но не реализовано - не ломаться и делать без явной выдачи ошибки". Там, где другая СУБД выругается и откажется - mysql сделает то, что внутри уже реализовано, пропустив то, что еще не реализовано. Это позволяет делать мультиплатформенный код и переносить НА mysql решения, которым не нужен check constraints например. Да, решение принимаете лично Вы, но переделывать ничего не придется с точки зрения кода.

И это осознанный выбор такого стиля. Что касается подключаемости движков - таки огромный плюс. Замена ISAM на приличные InnoDB или XtraDB это кошерно.



в этом сообщении нет смысла, если брать его в контексте того, что mysql - это хорошая субд относительно postgre. Потому что все тоже самое можно сказать и о последней.

Myisam и другие движки(кроме innodb), с большой долей вероятности, умрут страшной смертью и не получат развития.

У MySQL приличные проблемы с race conditions при Isolation в транзакциях. И эти проблемы даже по сравнению с postgre(в которой на некоторых уровнях все и больше работает из коробки, а mysql - надо пилить) - проявляются. (http://martin.kleppmann.com/2014/11/25/hermitage-testing-the-i-in-acid.html)

Я не понимаю вашего возвеличивания недосубд (даже на фоне той же постгри) mysql.

Ладно, базовые функции можно долго обсуждать, но когда возникают основательные проблемы при миграции данных со старой версии на новую - это серьезных подход?...Например,при обновлении с 5.6 на 5.7 после изменения допустимых значений для дат - пришлось заниматься сексом ночью с выпрямителем мозгов. Это к слову наличие check`а - который парсится, но никак не работает в mysql. Интересно, как будет проходить миграция после того, как он заработает..хотел бы я глянуть на эту боль.

К слову, я не апологет ни постри, ни противник майскуля, просто логику пытаюсь вашу понять.
27 дек 18, 14:19    [21774772]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Озверин
Andy_OLAP
Озверин,
Там, где другая СУБД выругается и откажется - mysql сделает то, что внутри уже реализовано, пропустив то, что еще не реализовано.

в этом сообщении нет смысла, если брать его в контексте того, что mysql - это хорошая субд относительно postgre. Потому что все тоже самое можно сказать и о последней.

Вы оставленное имеете в виду? Что PostgreSQL что-то подобное пропускает?
(Да, кстати, сокращённое название PostgreSQL --- postgres).

Озверин
У MySQL приличные проблемы с race conditions при Isolation в транзакциях. И эти проблемы даже по сравнению с postgre(в которой на некоторых уровнях все и больше работает из коробки, а mysql - надо пилить) - проявляются. (http://martin.kleppmann.com/2014/11/25/hermitage-testing-the-i-in-acid.html)

Мне MySQL тоже как-то неинтересен... но где Вы там увидели его проблемы?
Вот у Oracle, к примеру, они там есть (но это и так давно известно).

Озверин
Я не понимаю вашего возвеличивания недосубд (даже на фоне той же постгри) mysql.

А я не понимаю, на фоне чего у Вас эта гордыня в высказываниях? ;)

Озверин
К слову, я не апологет ни постри, ни противник майскуля, просто логику пытаюсь вашу понять.

Вы читали его сообщения про TPC-E и т.п.? И всё ещё пытаетесь понять логику, серьёзно? ;)
27 дек 18, 14:39    [21774811]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
PgSQLanonymous3, по ссылке есть репозиторий, где для разных уровней изоляции описаны аномалии, которые могут встретиться(или не встретиться).

https://github.com/ept/hermitage

dirty read у innodb mysql - сплошная проблема.
27 дек 18, 14:48    [21774832]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
PgSQLanonymous3, учитывая, что пишется везде PostgeSQL, то я автоматом SQL убираю.
Впрочем, в официальной вики постгреса тоже пишут postge SQL...что как бе заставляет удивиться вашему замечанию( и надобности его вообще в данном контексте).
27 дек 18, 14:51    [21774836]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7933
С PostgreSQL и MySQL секс имел только в конце 90-х.

Сначала был выбран PostgreSQL, но он в _тот_ момент полностью не работал. Нужны были таблички в 45 000 записей + таблица связей в 2 миллиона - без vacum'а не работало, а vacum ставил клином сервер на 2 часла, что для I-net проекта было недопустимо. В общем, PostgreSQL с матерными словами пришлось выбросить на помойку, как студенческую поделку вообще не приспособленную к жизни.

Перешли на MySQL, в нем не было целого ряда "нужных фичь", но в конце-концов, то что не понимал MySQL сделал руками через temporary table. Но тогда My SQL так себя и позиционировал: быстрая недо-база в которой не реализованы сложные фичи или фичи снижающие производительность - т.ч. никаких обид )))

В современное время, я вижу реально работающие в продакшене СУБД PostgreSQL и понимаю, что его все же допилили до работоспособного состояния. Читая доки по PostgreSQL, складывается ощущение. что по "движку" он примерно приблежается к Oracle 8i.

Насколько "родовые травмы" PostgreSQL (vacum и работа через ФС) критичны для нагруженных систем в продакшене - не знаю. Но опасения у меня все же есть, т.к. на реальных проектах с Oracle (когда работали через ФС) я видел, когда ОС при full table scan запросе из таблички большей чем память на сервере, думала, что компьютер это файлопойка, раздувала кэшь файловой системы по максимому и все приложения отправлялись в своп. На Oracle выличилось "волшебным пендалем" админу и включением Direct IO. Что при таком патерне запросов нужно делать с PostgreSQL - я не знаю.

Все было бы хорошо, если бы хотя бы были вменяемые доки по настройке ОС + PostgreSQL. Но обычно доки по ОС - отдельно, доки по настройки СУБД - отдельно. Читаешь и понимаешь, что одно противоречит другому. Не говоря уж о том, что ОС-писатели тоже изгаляются как могут: например опцию swappiness в ряде ОС сделали деприкайтет и выпилили, оставив полное непонимание, что же использовать вместо нее (((

Не админ. Тупо программер. Т.ч. по многим пунктам знания устаревшние лет на 5-8 (((.
27 дек 18, 14:52    [21774837]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Leonid Kudryavtsev
На Oracle выличилось "волшебным пендалем" админу и включением Direct IO. Что при таком патерне запросов нужно делать с PostgreSQL - я не знаю.

Таки ничего не нужно делать. Кроме как отказаться от ванильного postgresql в пользу творения Пострес Про, если есть лишние шекели.
27 дек 18, 17:18    [21775027]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Leonid Kudryavtsev,

В принципе, можете взять Oracle Linux 7 и подкрутить vm.dirty_ratio=10 и vm.dirty_background_ratio=5 (это в процентах). Или в байтах подкручивать vm.dirty_bytes и vm.dirty_background_bytes, плюс поиграть со значением vm.dirty_writeback_centisecs (возможно, еще и покрутить vm.dirty_expire_centisecs и vm.dirtytime_expire_seconds).

На x86 windows кэш ограничен хорошо. На x64 windows - ну разве что руками крутить скрипт powershell и в планировщик. Как платформа для СУБД - Windows подходит только для своей родной MSSQL, да и то не очень.
27 дек 18, 17:23    [21775030]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Dimitry Sibiryakov
Andy_OLAP
Там, где другая СУБД выругается и откажется - mysql сделает то, что внутри уже
реализовано, пропустив то, что еще не реализовано. Это позволяет делать
мультиплатформенный код и переносить НА mysql решения, которым не нужен check constraints
например.

Это было бы прелестно, но тогда почему он до сих пор использует обратные апострофы в
delimited identifiers и ругается на стандартные кавычки вместо "молчаливого пропускания"?..

Ну вот такая вот идея была - Backticks are to be used for table and column identifiers, but are only necessary when the identifier is a MySQL reserved keyword[/url]. Можете поменять [url=https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html]режим на ANSI, если понимаете, что именно делаете.
27 дек 18, 17:29    [21775041]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Andy_OLAP,
Исправляю предыдущее сообщение:
ссылка 1
ссылка 2
27 дек 18, 17:30    [21775045]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить