Безусловно MySQL прогрессирует и вбирает технологии

оно уже научилось check constraint?

особенно эта «нужная» ололитика: сколько пользователей лайкнуло наши продукты в фейсбуке но потом отказалось покупать в разрезе региона и цвета волос

смешно потому что ни в каких фейсбуках порнография вроде SQL не используется. SQL только в банках

нет никакой ложки никаких санкций

но ведь фб как раз на мускуле

но ведь фб как раз на мускуле

жать что в фб этого не знают и пользуются hadoop

Очень болею за PostgreSQL, хотел отказаться от MSSQL на работе, но сказали что уже пробовали, 1С глючила работая в этой среде.

Кто то сталкивался с таким?

С глюками не сталкивался. А работающие сайты 1С с PG в качестве БД - много где стоят и работают. Правьте руки тем, кто «сказали что уже пробовали»

MySQL только недавно начал становиться вменяемой базой

Github, Wikipedia, Google, Facebook, Twitter, LinkedIn, Alibaba, Taobao, Booking.com, AirBnB, Dropbox, Pinterest, GroupOn, Yelp

Треш, выросший из наколенных поделок.

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

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

Я о том, что если Oracle из-за санкций отозвал лицензию, российская компания обязана прекратить использование Oracle, иначе будет «пиратом» по российским же законам. Вот это действительно на мазохизм похоже.

Я о том, что если Oracle из-за санкций отозвал лицензию

Не отзовет, иначе потеряет много денег, а без возврата денег отзыв не будет действительным.

Просто нужно юзать нормальные ORM (в смысле, Hibernate), и стараться никогда не писать SQL руками, и всё будет хорошо

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

согласен, но не совсем. Чаще всего видел как «необходимость» возникала у людей, недостаточно хорошо понимающих Hibernate, не умеющих в ООП-дизайн итп. Самая частая ошибка - в неправильном проектировании базы и приложения - всё это должно быть четко заточено под Hibernate и его особенности. Имхо, можно множество типовых проектов «более-менее больших» написать, не написав ни одного прямого обращения к базе.

+ имхо надо сразу думать, что если есть какой-то необычный доступ к базе, его надо сразу же хоронить в толще абстракций. Например, расширяя тот же Hibernate. Или например, глянь на Spring Data (http://www.youtube.com/watch?v=nwM7A4TwU3M), чуваки три года писали экспериментальную обвязку для написания кода, который боле-менее легко можно отрефакторить под новую базку. Т.е. это вопрос правильной архитектуры системы. И строгой дисциплины, недопущения кривых рук анскильных лалок к фигачинью sqlя в окрытом виде.

Друг, ты уверен что ты очень хорошо разбираешься в базах данных и как они устроены?

Я вот - нет. Не всё так просто там, как кажется. Слава богу, когда я работал над проектами с действительно серьезными нагрузками там сидели профи которые делали грамотно Materialized views и вьюхи и для меня это было просто как api.

И тем не менее, стоимость лицензий для крупной компании меньше чем стоимость рисков.

Ты, надеюсь, понимаешь, что стоимость лицензии не отменяет стоимости рисков? Коммерческая БД точно так же «падает» и хоронит под своими обломками данные, как и некоммерческая. Разница лишь в том, что с лицензией твои данные будет искать разработчик базы, а без лицензии — твои же админы, сидящие у тебя на зарплате, либо одна из тысяч компаний, специализирующихся на такого вида работах. При чём, твои админы или наймиты приступают к работе сразу, а лицензиара — только после долгих переговоров, когда становится очевидно, что от работы не отвертишься.

Да и коммерческие СУБД гораздо лучше мастшабируются.

Спорное утверждение, требующее доказательств в цифрах.

Плюс большинство специалистов по базам данных на рынке труда обучены работать именно с oracle/mssql/db2.

Ещё более спорное утверждение. Опыт найма «специалистов по %databasename%» показал, что эффективнее искать «DBA с опытом работы» и смотреть на его знания SQL, понимание архитектуры баз данных, общие знания UNIX-подобных систем и — это критически важное и бескомпромиссное качество! — умение самостоятельно здраво мыслить и вникать в суть вещей. «Специалист по DB2 не нужен, родной».

И их услуги будут весьма не дешевы и не быстры.

Зависит от региона, но вообще не настолько дорого, как ты думаешь. За пределами кремниевой долины такой узкий специалист обойдётся в 120-150 тысяч долларов в год. Это уровень зарплат senior sysadmin в крупной компании в США.

Любопытно: до конца 2014-го года постгрес не был темой номер один везде, а потом как поперло-поперло. Казалось бы, при чем тут курс доллара?

Где гарантии, что этот специалист не типичный студент с лора, который уверн в себе, но всё сломает нахрен и убежит?

Эти гарантии стоят гораздо больших денег.

У меня чувство, что меня где-то обманывают. Пытаются меня убедить, что «MySQL только недавно начал становиться вменяемой базой», при этом многие компании зачем-то им пользуются уже довольно давно.

Тебя нигде не обманывают, просто у тебя мало опыта широкомасштабной разработки. Когда-то давно эти компании выбрали MySQL как самый простой для наколенной разработки продукт (ср. Facebook и PHP). А дальше произошёл экспоненциальный рост компании, в процессе которого сперва заменить базу на более производительную было некому (все разработчики заняты написанием новых фич), а потом — физически невозможно без кардинальных изменений в проекте. При этом вся стратегия развития проекта предполагала постоянный рост (опять же, самая «дешёвая» стратегия с отложенными последствиями), которая не оставляла никакой возможности для рефакторинга и пересмотра технического выбора. В итоге получились проекты, построенный вокруг MySQL и его недостатков (опять же, ср. Facebook и PHP). Большинство перечисленных команий, имей возможности для безболезненной и одномоментной замены MySQL, сделали бы это.

Сказки про портабельность кода на ORM слегка преувеличенны. Из первого, что приходит в голову - это разная обработка текстовых полей. Для MySQL по дефолту текстовые поля регистронезависимые, а у PostgreSQL все поля по дефолту регистрозависмые. Для регистрозависимых юзают citext. И ни один ORM с которым я работал (включая Hibernate) это никак не обрабатывает. Особа эта лажа заметна когда меняют БД, думая что вот мол юзали ORM и всё будет ок, а потом данные не импортируются.

Другой пример это разные экзотические типы, в каждой БД есть разные способы создания своих типов. Например в MySQL можно хранить IP адреса как поля типа INT (либо как BLOB для ipv6), а в PostgreSQL есть свой тип для этого. Конечно, этот случай можно обработать в ORM, но они по дефолту этого не делают и результат получиться всё равно не очень.

Ещё важный момент, это оптимизация. Любой большой нагруженный проект оптимизируют, в результате код становиться прибит к конкретной базе, иногда даже к конкретной версии базы.

Где гарантии, что этот специалист не типичный студент с лора, который уверн в себе, но всё сломает нахрен и убежит?

Рекомендации с предыдущего места работы. У специалиста по тонкостям pg есть длинный послужной список с указанием конкретных людей, которым можно позвонить и спросить. Студент с ЛОРа таким похвастаться не сможет, ему повезёт, если наймут интерном за 35к/год.

Эти гарантии стоят гораздо больших денег.

Гораздо — это сколько? 500 тысяч? Миллион?

MySQL быстрее на простых задачах. Часто нужно именно это.

Нет, и тесты это показывают. А так-то SQLite ещё быстрее. Но ведь мы же не об этом, правда? :)

Нужный для оракла и линукс и солярка стоят примерно столько же, если не дороже даже, как и серверные винды. Конечно, можно попытаться быть самым умным: купить Oracle, но поставить его на CentOS, тем не менее в серьезной фирме так поступать не станут.

Конечно не станут. Зачем ставить какой-то там CentOS, если можно поставить официальный оракловский линукс, который гарантировано совместим с Oracle DB?

смешно потому что ни в каких фейсбуках порнография вроде SQL не используется. SQL только в банках

В школе на перемене подслушал о чём старшеклассники беседуют? Facebook пользуется в том числе и SQL базами. Инфа из первых рук.

А тут не только деньги на лицензию на СУБД, а еще на лицензию на серверные винды

Чё сразу винды-то? Сам оракел всю жизнь в первую очередь ориентировался сначала на коммерческие юниксы, когда они подохли - на Ред Хат, теперь вот свою сборочку сделали.

То, что во многих конторах его предпочитали и предпочитают ставить на привычный Windows NT и его нынешние потомки - исключительно проблема образованности и фобий этих контор.

PostgreSQL лучше Oracle и MS SQL вместе взятых, или еще нет?

Oracle и MS SQL

Ларри возмущён, что ты его детище поставил рядом с каким-то MS SQL.

В первый раз вижу живого человека, не менеджера, которому искренне нравится оракел.

С точки зрения разработчика у оракела таки есть как минимум одно достоинство перед сабжем - пакеты. Приятнее и упорядоченнее, чем хранимые процедуры россыпью. Ну и синтаксис у PL/SQL в мелочах поприятнее, чем у PL/pgSQL, хотя во многом они похожи.

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

Т.е. это вопрос правильной архитектуры системы.

Хотите сказать, что когда не СУБД занимается целостностью и согласованностью данных - это правильная архитектура системы?

Чего я не понимаю, та это почему у нас не додумались внести исключение в законы, что отзывы лицензий по санкционным причинам недействительны.

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

Только СПО, которое можно развивать самостоятельно, даёт некоторую надежду на защиту от санкций, и то при условии, что _заранее_ создана необходимая инфраструктура.

И их услуги будут весьма не дешевы и не быстры.

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

А связавшись с Ораклом, ты делаешь ровно то, что требует от тебя Оракл, и при этом платишь ему деньги, много денег. Или через некоторое время выкидываешься на мороз. Поинтересуйся судьбой клиентов, разок не продливших годовую техподдержку.

Есть некая базовая модель, «что такое БД». В неё входит и кислота в том числе. Так что целостностью базы пусть занимается база, это входит в базовую модель. А вот какие-то специфические аналитические функции мы уже не сможем использовать, даже если они потенциально ускоряют софтину в 1000 раз.

MS SQL to PostgreSQL

На работе 1С 8.2 файловая, 10 пользователей, при переходе на 8.3 начали ощущать нехватку производительности. Попробовал пересадить на серверную Debian + PG SQL + тонкий клиент - проработали месяц без сбоев, с бекапами 2 раза в день. Но «зажали» покупку лицензии на сервер и пришлось вернуться на файловую(Debian + samba AD member + LVM).

Бухгалтерия 2.0, штук 10 баз разной степени наполненности бухгалтеров не так много человек 7, но у всех открыты все базы одновременно, поэтому подключений висит куча. С торговлей все хуже, 10.3 1С не стали переводить на использование управляемых блокировок, поэтому она висит на сервере с виндой, а переводить контору на 11 торговлю тоже удовольствие весьма сомнительное, тем более они сами не хотят.

Быстрее очевидно просто текстовые файлы в оперативной памяти. ACID — тормоз по жизни. Быстрая вставка в простую таблицу, как и чтение из неё в случае MySQL по-моему таки быстрее чем PostgreSQL, а бэкапы всё равно нужно делать везде.

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

А в каком докладе (и когда) будет рассказано как перевести миллионы строк PL/SQL из Oracle DB в PostgreSQL?

Ну так

Обе СУБД хорошо совместимы со стандартом ANSI SQL. Именно поэтому, пользователям Oracle научиться работать с PostgreSQL будет не так сложно.

А все, что вне ANSI SQL, в их вселенной, похоже, просто не существует.

Что тут непонятного?

Зачем крупным компаниям переходить на бесплатную СУБД? Для крупных компаний деньги на лицензии не проблема.

Ты действительно такой наивный? :)

смешно потому что ни в каких фейсбуках порнография вроде SQL не используется. SQL только в банках

:)

а у этой крутейшей субд поддержка мастер-мастер репликации из коробки в планах на ближайшую пятилетку уже появилась или это считается не нужно? нафиг нужна субд, которая не масштабируется и не поддерживает HA без кучи 3rd-party костылей и подпорок?

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

а во-вторых, вся эта многоуровневая транзакционность, процедурки, вьюшки и прочая тру-sql заумь нужна разве что в банках и в ентерпрайзе при архитектуре типа «один толстый сервер за сто тысяч долларов обслуживает 100500 клиентов, ворочает терабайтами данных и обрабатывает запросы с тысячей джойнов». подобная архитектура, как известно, со временем приводит в тупик, потому что масштабируется только вертикально.

будущее за лайтвейт машинами и выносом всего чего только можно (а можно много чего) в легко масштабирующиеся горизонтально и поддерживающие HA nosql решения на commodity hardware.

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

ORM - это хорошо, это отлично само по себе. Это настолько хорошо, что ради этого можно тер+петь побочные эффекты типа десятикратных просадок производительности и ограниченной функциональности. Представление об отказе от нативных функций базы у меня имеется.

Понимаешь, ты никому не сможешь продать приложение, которое ты НЕ написал. Потому что его нет. А не написал ты его потому, что писать логику со стороны базы и потом пробрасывать ее на клиентское приложение - оооочень медленно, оооочень сложно и оооочень больно.

Больно потому что результат говно. А говно потому что нет ни хороших языков программирования, ни хороших инструментов. Например, чтобы отдебажить сторед-процедуры на MySQL нужно устанавливать на компьютер Шиндовс и дебажить в Вижуалке, и от качества этого дебага слезы наворачиваются. А сами сторед-процедур какие? В смысле, сам язык программирования говно (синтаксис рядом не стоял с C#), фичи говно (я могу в mysql из процедуры сгенерить и вернуть временную многомерную таблицу?), фреймворков никаких нет, а чтобы притащить их (в виде написания экстеншенов к базе данных) надо разбиться в лепешку. В результате вместо нормального кода получаются миллионы бесконечных портянок адового блевотного говна, в котором никак не разобраться (даже с поллитрой не разобраться).

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

Более того, разобраться в Hibernate сложно, но писать хороший код под базу еще сложнее, и это точно НЕ осилят твои толпы анскильных лалок с зарплатой 35 тысяч рублей, то есть часто это не просто «сложно» (=неприятно с этим говном возиться), а еще и «невозможно»(=выходит за пределы возможностей команды программистов)

Да еще, насчет говнорезультата. Специалисты по написанию логики на C# или Java (да, те которые с зарплатой 35 xD), скорей всего специалисты только в этом. Им хотя бы то что они пишут правильно отстроить. А если они каждый раз будут метаться к оракл-программисту, чтобы он написал им stored-процедурку, это сразу пиши пропало - архитектура клиентского приложения превратится в говно, а бизнес-процесс встанет на ожидании отклика оракл-программистов.

Иначе говоря, пока вы там геморроитесь со своим SQLем, другие чуваки навертят то же самое на своем говнеце за полгода, продадут, а ты останешься с носом, даже если внезапно, вдруг твое решение окажется лучше. Ту-ту, время ушло.

Более того, если ты сделал софтину, а ее некому продать - снова вся работа впустую. А например, если ты сделал софтину для электронного документооборота для оракловской базы, но вокруг все госорганизации сидят на Постгресе (или наоборот - сделал на постгресе, уехал в америку, а там все сидят на оракле), то ты в жопе - никому ты ее не продашь, а рефакторинг под новую базу потребует переписывания 90% проекта.

Так что написание логики на клиенте, и использоание ORM как одно из лучших фреймворков для этого - имхо это основа любого современного проекта не упирающегося в производительность (можно отмасштабироваться горизонтально при просадках, например).

Вроде бы, этот спор похож на часто поднимающийся здесь «почему не нужно писать на C и C++». Потому что на них писать медленно, сложно и больно. В то же время можно выбрать Java или C#, и можно будет выдать хороший результат, быстро сделанный и переносимый между платформами (аппаратными и даже операционками). Пока кодер на Java сохнет, кодер на C++ сдохнет. Да, Java и C# тормозят, но это не играет никакой роли, если альтернатива этому - не иметь никакого продукта, или никому его не продать.

восемьнадцать чаев mysqlей этому анонимусу!

В России вот уже несколько лет наблюдается масштабное движение отказа от проприетарных СУБД.

Ловите наркомана!

Типа, пусть сдохнет от разрыва мочевого?

Но «зажали» покупку лицензии на сервер и пришлось вернуться на файловую(Debian + samba AD member + LVM).

До 12 подключений сервер 1С на linux может обслужить без серверного ключа. На 10 пользователей можно было и не разоряться.

Куча бла-бла-бла поскипана

В то же время можно выбрать Java или C#, и можно будет выдать хороший результат, быстро сделанный и переносимый между платформами (аппаратными и даже операционками).

Когда в первый раз столкнулся под офтопиком с драйверами и прикладным ПО для принтера на ".net", хотелось порвать как Тузик грелку и этих коре-писак, и вот таких «альтернативно-одарённых», которые их убедили в том, что так можно делать.

И иди уже тогда до конца, и используй и БД, написанную на .net/jvm - их есть и не мало, а их функционала достаточно для всех ORM вместе взятых и каждого по отдельности. Даже такой тормоз сможет выполнять свои функции там, где нагрузка на него будет позволять ему сохранять отзывчивость.

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

Так что перестань натягивать РТИ №2 на глобус и выдавать свой мирок за всю вселенную.

Да чо с ним разговаривать, он же сраный формошлепщик и большинство его друзей используют mssql. Вполне себе диагноз.

И иди уже тогда до конца, и используй и БД, написанную на .net/jvm

в смысле, Apache Cassandra, одну из лучших баз для высоконагруженных проектов? Да, отличная идея.

в смысле, Apache Cassandra, одну из лучших баз для высоконагруженных проектов? Да, отличная идея.

Шедеврально!

Ну давай, натяни на кассандру свой любимый ORM, потом реализуй на нём ACID, потом наверни сверху бизнес-логику, и приходи со своей скорострельностью.

Но ты совершенно прав - нагружена твоя кассандра будет до потери отзывчивости шелом.

Да, запускает - так оно и работало, но по факту: 1. это «неправильно», и в случае проверки - «вежливо попросят» купить лицензию :) 2. это фича была оставлена 1Совцами для тестирования работы сервера под Linux и её могу прикрыть с любым релизом.