|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonЯ как-то делал экспорт (или дамп?) средствами mysql одного тестового проекта. И меня очень сильно удивил формат dml операций insert, где вместо кавычек по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону). Словом шлак. Совершенно непонятно чем создателям не подошли обычные quot, apos.А ты подумай. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 21:43 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mad_nazgulP.S. Сколько сталкивался с MySQL он везде мне доставлял проблемы. Причем понять, почему очень сложно. Т.к. он не ругался на ошибки, а что-то делал. Причем как сам это понимал. С PostgreSQL проще. Он сразу говорит - тут фигня. Присоединяюсь. Не раз с майсиквелом попадали в ловушки. С PG как то все более предсказуемо. Шо касаемо производительности, дак вот чего хотел бы сказать, На простых вещай, равного майсиквелу нет и не будет, он всех обскачет. Но как только база росла, то нетривиальные запросы он начал жутко ступорить, я бы сказал даже впадал в кому на пару минут. Чего тока не делали. Кончилось тем что сделали миграцию с майсиквела на Аракакл и готовы были купить стандард эдишэн. Но та миграция так и не попала на продуктовку. когда Аракакл обрезал ядра у стандарт эдишэн, решили его прокинуть и смигрировать на Постгрес. На одинаковом железе и одной и той же оське ( OEL7 ) Постргес и Аракакл показали примерно одинаковые результаты. Тесты не какие то абстрактные бэнчи, а реальное Web приложение. Не, не подумайте, я не загоняю майсиквел в полный ацтой, у него есть своя ниша, и он ее прекрасно держит. Но для энтерпрайс систем или тем более банкинга я бы его не пользовал. Его красота и простота в конце концов апсирается кучей проблем и косяков. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 21:57 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
ad-dc, Да ладно вам. Раньше и банкинг и энтерпрайз на dBase и клиппере писали и ничего. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:13 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HunterА ты подумай. Это прозвучало грубо. Как-то ... недостойно пятничной дискуссии. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:42 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton, Просто не ожидал от такого уважаемого мембера поста, как этотmaytonИ меня очень сильно удивил формат dml операций insert, где вместо кавычек по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону). Словом шлак. Совершенно непонятно чем создателям не подошли обычные quot, apos Если-бы были апострофы (') то поля превратились бы в литералы-строки. И меня это не удивило ни разу. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:59 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HunterЕсли-бы были апострофы (') то поля превратились бы в литералы-строки. И меня это не удивило ни разу. А почему они не превращаются в других форматах экспорта или дампа от других производителей dbms? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:13 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton, У MSSQL скобками полей являются [field], что еще хуже, т.к. их два а не один, как в MySQL. По-моему довольно изящное решение. Респект создателям однозначно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:21 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonА почему они не превращаются в других форматах экспорта или дампа от других производителей dbms?По-моему одинарный квот - везде признак строки-литерала. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:27 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HuntermaytonА почему они не превращаются в других форматах экспорта или дампа от других производителей dbms?По-моему одинарный квот - везде признак строки-литерала. А ты подумай (с) тролл на самом деле нет,и уж тем более обратный ` ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:54 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivКстати, вот подсистема, которая в MySQL всё же сделана лучше, это -- кодировки строк и collations. В PG -- отдано на откуп библиотеке C, что ну совсем странно для СУБД. В Postgres 10 обещают поправить ситуацию с collation ICU support ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2017, 17:41 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Любая СУБД в тех или иных вопросах идёт навстречу пользователю. Одна больше, другая меньше. Если бы какая-то СУБД строго придерживалась стандарта - у неё не было бы массы проблем, но и почитателей было бы мало. Те же квотеры для имён - да нахрен они не нужны, если твёрдо сказать, что строго А-набор, никаких там кириллиц-пробелов-ведущих цифр-зарезервированных слов. Вот только идиотов дохрена, и все они, за редчайшим исключением, дружно взвоют и бросятся искать другую СУБД, где их будет не гнобить, а холить, лелеять и облизывать. Вот и придумывают в плюс к стандарту, кто квадратные скобки, кто бэктики, кто двойные кавычки... MasterZivмного storage endgine никому не нужно. Нужен ОДИН, но ХОРОШИЙ и транзакционный. Не говори ерунды. Нафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? Значит, уже как минимум два движка, а не один... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2017, 17:00 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinaНе говори ерунды. Нафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? Значит, уже как минимум два движка, а не один...Значит, там и СУБД, скорее всего, не нужна. ;) Т.е. остаётся только DWH... или что-то ещё? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2017, 19:11 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PgSQLanonymous3Значит, там и СУБД, скорее всего, не нужна.Ага, и давайте по старинке работать с plain text. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 07:37 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Мы и сейчас работаем с plain text в части ini-files, properties, cfs-s. e.t.c. Весь линукс конфиг стоит на таких маленьких текстовых файликах. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2017, 16:55 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 07:57 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinamaytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? потому что удобно. в mysql оно из коробки. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 14:32 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
ScareCrowв mysql оно из коробкиИ какой движок обрабатывает таблицы, хранящиеся в формате таких файлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 19:59 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinamaytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? Какие три сообщения? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 20:24 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton AkinaНафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? PgSQLanonymous3Значит, там и СУБД, скорее всего, не нужна. AkinaАга, и давайте по старинке работать с plain text. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 21:48 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Akina, по большему счету именно наличие транзакций и разделяет DBMS от обычных сериализуемых на диск структур данных. Обычно DBMS дает гарантии. Лично для меня DBMS - это как Швейцарский банк. Если я что-то туда положил - то я уверен что это что-то там надёжно хранится. Бэкапится. И версионно шарится. Если вам вдруг (на минуточку) показалось что это неважно. И что mayton гонит чепуху. И эту часть теории можно отбросить и каким-то образом перепрыгнуть из согласованного чтения в грязное - то представьте что в этой базе лежат Ваши Деньги. Натурально... там лежит мать его ваш счёт. И с этого момента ваши отношения и пожелания по технологиям DBMS станут внимательными и проникновенными. Вот почему MyISAM нужно выбросить в печку. А всех кто его использует - подвергнуть химической кастрации по всем Европейским нормам этой мед-процедуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 22:00 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton , как я понял, Вы принципиально отказываете в праве на существование, например, RO-данным в БД. И даже insert-select данным. Т.е. тем, где от наличия транзакций не холодно не жарко. Вот нехрен в DBMS лезть, сериализуйтесь в текст, а если хотите потом быстрые выборки и статистики - придумайте, нафига вам нужны транзакции, и используйте их. Мало ли, что они тут ни к селу ни к заднице, есть такое слово - надо! Не все БД - это БД Швейцарского банка. Не смотрите на мир одним глазом - кривая картинка получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 22:24 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Я не отказываю. Пускай живут. Просто вывеску сменить нужно. Это как в математике. Я говорю пусть X - комплексное число. И все глубоко вздохнули и представили. Окей. Теперь корень их отрицательных излекается. Сложение - как векторное. Умножение - вращение и т.д. Всё! Действуют законы и гарантии. Если вы говорите окей. Пусть я работаю с табличкой в базе данных. Все представили себе ACID и совокупность правил и гарантий как с этим работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2017, 08:45 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlВ Postgres не нравится что версионность реализована на уровне строк, даже если ты изменил 0 на 1, все версии строк хранятся там-же где и актуальная строка, соответсвенно достум не по индексу будет медленней, ну изменение ctid и соответсветенно обновление всех индексов. Это идеальное решение для пост-реляционных систем. Данные и сегмент отката лежат вместе. Фактически нет разницы. При наличии толстого диска и редких OLTP операций мы можем поднять историю всех изменений за все года. При этом не нужен бекап. Это просто ретроспективный запрос по той-же таблице. В Oracle такое достигается только после активации flashback технологии. А это дополнительные дисковые расходы к тому что уже и так есть. В Postgres это из-коробки. Вобщем оба кейса хороши. Надо только найти им подходящие бизнес постановки. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2017, 23:30 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton В Postgres это из-коробки. гм, поясните пожалуйста. Нет в версионности ничего такого "При наличии толстого диска и редких OLTP операций мы можем поднять историю всех изменений за все года". Такое потребовало бы хранить абсолютно все версии всех записей, что означало бы, что данные не заменяются, а просто накапливаются. И уже через пару месяцев производительность такой системы была бы близка к нулю. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 01:05 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonЭто идеальное решение для пост-реляционных систем. "Постреляционная" - всего лишь реклама СУБД Cache, за которой не кроется ничего реального. Но кроме реляционных, есть более новые NoSQL-базы (правильнее было бы называть их нереляционными). Они в овсновном делятся на документо-ориентриованные (вроде MongoDB) и базы для больших объёмов данных (big data) (пример - HBase). В MongoDB и HBase транзакций нет, и смысл в их отсутствии есть. А популярность этих систем показывает, что они разработаны удачно. В общем, заглянул сюда за сравнением, но знатоков не оказалось. По-моему, участниками обсуждения упущено важное условие выбора - средства обеспечения сохранности данных: архивации и репликации (входящие в комплект и дополнительные, бесплатные и коммерческие, их возможности и качество работы). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 10:09 |
|
|
start [/forum/topic.php?fid=35&msg=39489408&tid=1552235]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
141ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
others: | 233ms |
total: | 491ms |
0 / 0 |