LINUX.ORG.RU

О миграции на Postgres в крупных российских компаниях — на открытой встрече #PostgreSQLRussia в Mail.ru Group

 , , ,


1

5

3 ноября 2015 года состоится очередная встреча сообщества #PostgreSQLRussia. Встреча пройдёт в московском офисе компании Mail.ru Group. Тема — нюансы перехода на PostgreSQL с других СУБД.

В России вот уже несколько лет наблюдается масштабное движение отказа от проприетарных СУБД. Многие крупные компании уже мигрировали или находятся в процессе миграции на PostgreSQL. Их опыт интересен не только с точки зрения самого процесса миграции. Крупные проекты, перешедшие на Postgres, могут поделиться новым, уникальным опытом, что безусловно полезно и тем, кто использует Постгрес давно.

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

Далее — ориентировочный план встречи.

1. Павел Лузанов, Postgres Professional (http://postgrespro.ru/). PostgreSQL для пользователей Oracle.

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

2. Илья Космодемьянский, PostgreSQL-Consulting.com (http://postgresql-consulting.com/). Pragma autonomous_transaction

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

3. Андрей Кондрашов, Банк Москвы (http://www.bm.ru/). Об опыте перехода на PostgreSQL в крупном российском банке.

Название и содержания доклада уточняются

4. Дмитрий Кремер, МИА «Россия сегодня» (РИА Новости, http://ria.ru/). Об опыте перехода на PostgreSQL в крупном информационном агентстве.

Название и содержания доклада уточняются

5. Борис Верюгин, Диасофт Платформа (http://www.diasoft-platform.ru/). Автоматизированные механизмы миграции приложений с СУБД Oracle на СУБД PostgreSQL.

В докладе речь пойдёт об опыте миграции с Oracle на Postgresql компании «Диасофт Платформа» и продукте «Diasoft Database Adapter», предназначенном для миграции приложений.

Кроме того, во встрече будет участвовать VIP-гость — Брюс Момджан (Bruce Momjian, http://momjian.us/), сооснователь проекта PostgreSQL, один из лидеров PostgreSQL Global Development Group (PGDG) и эксперт компании EnterpriseDB (http://enterprisedb.com/), основной продукт которой, Postgres Plus Advanced Server, является расширенной коммерческой версией PostgreSQL, призванной облегчить миграцию с СУБД Oracle.

Предварительная запись на встречу — на страничке сообщества: http://www.meetup.com/postgresqlrussia/events/225208401/ (также потребуется доп. обязательная регистрация на странице Mail.ru Group, будет объявлено отдельно)

Обсуждение и онлайн-общение на тему PostgreSQL: http://postgres.chat

>>> Подробности

Ответ на: комментарий от Evgueni

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

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

ukr_unix_user ★★★ ()
Ответ на: комментарий от bl

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

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

Karapuz ★★★★★ ()
Ответ на: комментарий от TERRANZ

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

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

Karapuz ★★★★★ ()
Ответ на: комментарий от weare

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

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

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

anonymous ()
Ответ на: Внезапно недавно от Camel

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

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от praseodim

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

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

praseodim ★★★ ()
Ответ на: комментарий от praseodim

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

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

weare ★★ ()
Ответ на: комментарий от autonomous

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

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

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

pawnhearts ★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от pawnhearts

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

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

anonymous ()

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

lgbt ()
Ответ на: комментарий от anonymous

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

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

pawnhearts ★★★★ ()
Ответ на: Чувство растяжимости от Camel

Re: Чувство растяжимости

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

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

anonymous ()
Ответ на: комментарий от stevejobs

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

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

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

anonymous ()
Ответ на: комментарий от pawnhearts

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

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

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

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

anonymous ()
Ответ на: комментарий от Evgueni

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

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

anonymous ()
Ответ на: комментарий от praseodim

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

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

anonymous ()
Ответ на: комментарий от Karapuz

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

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

anonymous ()
Ответ на: комментарий от praseodim

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

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

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от weare

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

Oracle и MS SQL

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

hobbit ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

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

O02eg ★★★★★ ()
Ответ на: комментарий от praseodim

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

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от O02eg

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

stevejobs ★★★☆☆ ()
Ответ на: комментарий от weare

MS SQL to PostgreSQL

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

antofka ()
Ответ на: комментарий от stave

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

AleksK ()
Ответ на: комментарий от anonymous

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

Evgueni ★★★★★ ()
Последнее исправление: Evgueni (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

v9lij ★★★★★ ()
Ответ на: комментарий от anonymous

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

Ну так

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

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

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

ak398979 ()
Ответ на: комментарий от pawnhearts

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

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

ak398979 ()
Ответ на: комментарий от Karapuz

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

:)

ak398979 ()

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

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

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

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

anonymous ()
Ответ на: комментарий от stevejobs

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

anonymous ()
Ответ на: комментарий от v9lij

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# тормозят, но это не играет никакой роли, если альтернатива этому - не иметь никакого продукта, или никому его не продать.

stevejobs ★★★☆☆ ()

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

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

anonymous ()
Ответ на: комментарий от stevejobs

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

anonymous ()
Ответ на: MS SQL to PostgreSQL от antofka

Re: MS SQL to PostgreSQL

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

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

anonymous ()
Ответ на: комментарий от stevejobs

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

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

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

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

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

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

yyk ★★★★★ ()
Ответ на: комментарий от yyk

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

anonymous ()
Ответ на: комментарий от yyk

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

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

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

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

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

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

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

yyk ★★★★★ ()
Ответ на: Re: MS SQL to PostgreSQL от anonymous

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

antofka ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.