Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:

ANS>>>Самая большая проблема — DDL. Любое применение DDL это даунтайм.
G>>Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей?

ANS>29'294'914 строк. Estimate — 5 часов.

G>>Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/

ANS>Да? Что я вижу:
ANS>

...30 million rows...
ANS>ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.

ANS>Почти мгновенно

Ключевое выделил. Не делай так. Просто не делай. Есть другие способы.

ANS>>>Именно отсюда растут ноги у всяких sсhema-less способностей.
G>>они совсем из другого места растут.
ANS>Но, почему-то акцентируется именно возможность гибко менять схему. А не возможность простого хранения абстрактных неструктурированных данных.
"Гибко менять схему" фактически означает забивать на целостность существующих данных при изменениях схемы.

ANS>>>Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим.
G>>Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.

ANS>Не умею. Научи.
Дорого тебе это выйдет.

ANS>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.
А это и не нужно.

ANS>>>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.
G>>MySQL — база для домашних страниц.
ANS>Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.
У них спроси.

G>>Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.
ANS>Никогда не лазил в исходники ни MySql ни Postgres. Что я потерял?
Ничего, но и не приобрел тоже.

ANS>>>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу.
G>>Точно, вот только есть два простых факта:
G>>1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.
ANS>Но не понятно откуда тогда эти кеши появляются если они никому не нужны.
Зачастую как раз от того что люди не умеют работать с SQL

G>>2)Если всетаки понадобятся вагоны "кешей, шардов и реплик", то это решение уже будет приниматься на основе имеющихся данных, профиля их использования итп.
ANS>Да, плохо только, что принимаются во внимание "имеющихся данных, профиля их использования" и неберутся во внимание вопросы консистентности.
См пункт 1.