Запоздалый слоупок запоздал

[metaclass]

БД без SQL

Скажите, это что за новая шиза в последнее время? Т.е., оно понятно, что SQL не обязательно нужен для задач типа "храним список пользователей и их мессаг на форуме", поэтому быдло-веб-пхп-программерам РСУБД, реляционнная алгебра и SQL кажется специальным садизмом по отношению к ним со стороны высоколобых энтерпрайз-коллег и маркетинговой дурью.

Но даже без этого начинается какая-то бредовая движуха, толкают какие-то говно-key-value db, какие-то hadoop, couchdb, cassandra и прочий трэш, который 100% будет пионерскими поделками, потому что невозможно написать нормальную новую БД, не будучи в состоянии осилить РСУБД и SQL.

Это как постреляционные СУБД. Вроде они есть, но на самом деле их нет - они продаются исключительно единичным заказчикам, паровозом вместе с софтом, который купили бы в любом случае, даже если бы он использовал хранилище в плоских файлах в виде компилируемых исходников, а данные бы туда сохранялись кодогенератором. Типа специализированного медицинского софта или там какого-нибудь "ПО для управления ДНК-секвенсором"

Comments

[spushnyakov.livejournal.com]

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

[alll]

http://dz.livejournal.com/557602.html?style=mine

[w00dy.livejournal.com]

Я думал у себя в однмо мелком прожекте bdb поюзать, но потом передумал. В итоге каждый объект положил в отдельный xml с id в качестве имени, прикрутил простой Dictionary<> в качестве кеша и положил рядом index.xml. Просто, работает и даже относительно быстро.

[volodymir-k.livejournal.com]

Зря нервничаете, подход тоже имеет право быть. Разумеется есть ограничения, за их счёт получаем некоторые выгоды. SQL БД это классические вещи с гарантиями, транзакциями и т.д., которые в некоторых задачах не нужны. Например, "говно-key-value db, какие-то hadoop" это примерно то, что используется в Гуголе ("100% будет пионерскими поделками"). Понятно, что можно гугол построить чисто на Оракле, да вот "почему-то" не стали.

> или там какого-нибудь "ПО для управления ДНК-секвенсором"

Исключительно грамотное применение инструмента. SQL туда можно прикрутить, НО ЗАЧЕМ??? Смысла нет никакого.

[lionet.livejournal.com]

Да нафиг это не нужно, кроме как в highload проектах. Но всем кажется, что именно у них — highload проект, или станет таковым.

[alexott.livejournal.com]

что-то у тебя все в кучу - hadoop - реализация map/reduce на базе которой есть hbase, которая реализует распределенную БД
P.S. эти БД возникли в ответ на необходимость хранения неструктурированной информации, часто в распределенной среде. у них есть свои варианты использования, не все в оперднях использовать

[aamonster.livejournal.com]

Ну, sql не всегда был. Есть люди, начинавшие с dBase II :-)

[sorhed.livejournal.com]

Не надо путать документно-ориентированные базы данных (типа CouchDB и иже с ними) и, эм, record-ориентированные (реляционные). Вот для чего нужны key-value БД я ещё не допёр, но прозреваю, что и им где-то есть применение.

Разумеется, выть на всех углах «SQL не нужен» — это как бы признак неадеквата, да, но это не означает, что всё должно быть SQL.

[wizzard]

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

в других случаях оно кагбе нафик не нужно, но все верят, что у них будет хайлоад.

карго-культ, вообщем.

[zmila.livejournal.com]

"Не понимаю, почему люди, прежде чем делать такие заявления, не изучают предмет, про который пытаются рассуждать. " (ц) :))

[dmzlj.livejournal.com]

ну считается что оно должно быть эпически быстрое и масштабируемое

[develop7]

Блядь, ещё один специалист по всему.

[permea-kra.livejournal.com]

1. Без SQL не обязательно нереляционная.
2. Может захотеться хранить иерархических данных без необходимости ходить по ним руками и при этом не держать данные в памяти целиком (из-за размера).

[sergiej.livejournal.com]

Шиза это пихать РСУБД везде где надо и не надо не включая мозг.

[dz.livejournal.com]

Есть, на мой взгляд, два основных фактора.

1. Тот, который Вы обозначили. Я бы назвал его "фактор PHP". Пэхапе - редкое уёбище, но в него очень просто въехать и потому оно популярно в народных массах. mysql без транзакций - та же жуть, но победное его шествие нельзя игнорировать. в программирование вброшены огромные массы неумелых людей, отсюда востребованы любые корявые, но простые вещи.

2. Тот, в который Вы не верите. У нас на первом Четверге в DZ был рассказ о том, как в Яндексе был введён в продакшн map-reduce style обсчёт статистики, почему он был введён и почему SQL в этом месте не подходит. Коротко: потому что на статистике не нужна ни интегрити, ни гарантия сохранности данных. При этом мап редьюс даёт линейную (практически проверено) масштабируемость.

Насчёт сырости - вторым выступлением у нас был Микрософт, который в рамках azure продаёт доступ к key/value db, при этом, на секундочку, предлагает SLA. Лично свою руку я на отсечение не дам, но я очень сомневаюсь, что Микрософт подпишется под SLA, если технология сыра.