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

[metaclass]

БД без SQL

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

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

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

Comments

[spushnyakov.livejournal.com]

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

[kong-en-ge.livejournal.com]

А построить свое казино с блэкджеком и шлюхами?

[dz.livejournal.com]

А что, ТРЯП в России уже не преподают? Написание компилятора - работа на два вечера для нетупого студента.

Вот написание ХОРОШЕГО компилятора для ОБЩЕЦЕЛЕВОГО ЯП - это другой вопрос. (И то - с появлением JVM перестало быть проблемой.) А написание компилятора для DSL должно быть в колоде каждого серьёзного разработчика одной из боевых карт.

Ну и всё остальное тоже.

Вы не видели evernote? За разработкой этого проекта стоит Пётр Квитек. Он написал ОО СУБД, которая лежит в основе сервиса, примерно за три месяца.

Жопа в том, что для современного русского программера всё это - вещи от бога, которые простой чел сделать не может, можно только купить в америце. Деградировала профессия. :(

[metaclass.livejournal.com]

Признаюсь в грехе - я в 2000 году для одной бухгалтерской софтины на дельфи сделал объектную БД. При этом весьма смутно осознавая теорию того что я делаю :) В итоге, как оказалось, применил несколько идей из функционального программирования, только не знал, что они уже придуманы до меня.

[dz.livejournal.com]

наш человек. :)

[pavel-valerich.livejournal.com]

что интересно, теперь в evernote for Windows используется sqlite

[alll]

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

[theiced.livejournal.com]

не надо ссылки на этого ушлёпка постить, пожалуйста.

[w00dy.livejournal.com]

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

[metaclass.livejournal.com]

Ебаныйкошмар, простите мой французский. :)
Хотя я вот то же самое сделаю, если не смогу sqlite заставить понимать мои запросы.

[w00dy.livejournal.com]

Я вот sqlite теперь только как базу для embedded приложений рассматриваю, ибо в большом рабочем прожекте мы уже поняли какое оно ёбаныйкошмар. А что что я сделал - для мелких применений то что доктор прописал. У меня всего 6 классов, каких-то супер развесистых структур нет. Нахуану сюда тащить какой-то sqlite или что-то ещё и пол дня ипаццо и писать какие-то обёртки.

[metaclass.livejournal.com]

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

[nivanych.livejournal.com]

Кстати, ребе, расскажите, чего вам в sqlite не хватает?
А то ж, я тоже собрался его пользовать, вот и думаю,
не напорюсь ли на какое некрасивое...

[metaclass.livejournal.com]

http://metaclass.livejournal.com/462858.html?thread=4872714#t4872714
чо-то я не так делаю и у меня такой запрос не работает

[nivanych.livejournal.com]

Ага, спасибо.
У меня, вроде, такого не будет.

[volodymir-k.livejournal.com]

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

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

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

[dz.livejournal.com]

exactly.

[lionet.livejournal.com]

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

[vadun.livejournal.com]

+1
всякие фейсбуки, твитеры и прочие гуглы поднимают buzz, а остальные подхватывают

[lionet.livejournal.com]

Twitter был вынужден _влиться_ в это движение, ибо MySQL его достал. Фейсбук был вынужден возглавить это движение (Cassandra, current favorite) — потому что MySQL его тоже достал. И только Гугл (и, отчасти, Amazon) — сразу понимали, что SQL достанет, и делали сразу по-уму.

[vashik.livejournal.com]

Что значит сразу по уму? Говорят, у Google до сих пор Adword на MySQL работает.

[lionet.livejournal.com]

man BigTable, да?

[tretiy3.livejournal.com]

ну а если другая крайность. никакая нагрузка. немного данных. почему не взять объектную базу (в случае ооп) и не писать сразу персистентные объекты, не заморачивась вообще на sql, orm и т.п.?
или, там, фишка таких баз - schemaless. т.е. никакого "проектирования" таблиц и зависимостей. понадобилось - вкрутил.
такие штуки не рассматриваете?

[metaclass.livejournal.com]

С "никаким проектированием" - непонятно. Если у меня уже лежит в хранилище 10000 объектов, и мне вздумалось изменить их формат, или хуже того, поменять структуру связей - тут хоть объектные, хоть реляционные базы, но без плясок с бубном с миграцией не обойтись.

Да и с запросами не совсем понятно, хотя с LINQ в последнее время с этим проще.

[tretiy3.livejournal.com]

ну, это другой, на самом деле, подход. у этих 10000 объектов нет никакого формата, понимаешь?

например, у тебя хранилище "отчеты". и ты валишь туда отчеты, естественно. не важно, причем, это xml файлы, или некие объекты, построенные по этим xml файлам.

у тебя есть индекс, который выгребает из хранилища "отчеты" нечто, у чего есть тег <balance>. ты это нечто обрабатываешь в "виде" и выплевываешь клиенту.

через год тебе говорят: товарищ, теперь отчеты будут еще в xls файлах. ты говоришь ок, и дописываешь в свой индекс (а он руками пишется на языке разработки) код, который теперь проверяет на xml/xls и в первом случае, работает по старинке, а втором парсит xls файл, находит ячейку со значением balance и индексирует твой объект по значению, например, той ячейки, которая справа от этой ячейки.

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

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

[osdm.livejournal.com]

А потом внезапно у тебя этих -ов становится не 10 000, а миллион, и все начинает по дикому тормозить. На dailywtf был классический пример. Люди строили карточную систему для американского универа и его общаги. И тоже решили, что БД им не к чему - данных-то раз два обчелся, сколько их там, этих студентов. Итог: на проверку прав тратилось по три секунды, прикладывать карту приходилось 2-3 раза, а баланс с карты списывался только на следующий день. Почитай http://thedailywtf.com/Articles/We_Don_0x27_t_Need_No_Stinkin_0x27__Database.aspx

База данных - это на самом деле намного проще, чем все эти файловые хранилища, особенно с современными ORM-мами.

[dz.livejournal.com]

не совсем. keyvalue в этой ситуации ведёт себя куда спокойней SQL. Старые данные остаются в старом формате, новые - в новом. При этом функции деградируют ЧАСТИЧНО. Где-то не будет показано поле, где-то сдохнет гиперссылка.

Этот подход бесит привыкших к порядку, но он очень жизнеспособен.

Если не хранить так банковские транзакции. :)

[alexott.livejournal.com]

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

[aamonster.livejournal.com]

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

[pascendi.livejournal.com]

Когда появилась db II, SQL уже был в природе.
Только не был доступен тогдашним советским наколенникам :-)

[aamonster.livejournal.com]

В природе - был, но...
1980 - dBase II под CP/M-80 ( http://ru.wikipedia.org/wiki/DBase )
1986 - первый стандарт языка SQL ( http://ru.wikipedia.org/wiki/Sql )
Т.е. безотносительно к советским наколенникам - по факту SQL на персоналках не было, и вообще он был доступен не всем.

[metaclass.livejournal.com]

я с Clipper начинал :)

[aamonster.livejournal.com]

Заклеймлен как слишком молодой и не знающий истоков :-)

[nivanych.livejournal.com]

Да, это сказака ;-)
Я чуть помоложе буду, поэтому, я на нём
только мелкую полутестовую фигню долбил чуток.

[sorhed.livejournal.com]

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

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

[wizzard]

кстати да, +1. и еще не надо пытаться из док-ориентед делать все остальное (а пытаются)

[wizzard]

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

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

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

[zmila.livejournal.com]

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

[develop7]

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

[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, если технология сыра.

[metaclass.livejournal.com]

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

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

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