![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Запоздалый слоупок запоздал
БД без SQL
Скажите, это что за новая шиза в последнее время? Т.е., оно понятно, что SQL не обязательно нужен для задач типа "храним список пользователей и их мессаг на форуме", поэтому быдло-веб-пхп-программерам РСУБД, реляционнная алгебра и SQL кажется специальным садизмом по отношению к ним со стороны высоколобых энтерпрайз-коллег и маркетинговой дурью.
Но даже без этого начинается какая-то бредовая движуха, толкают какие-то говно-key-value db, какие-то hadoop, couchdb, cassandra и прочий трэш, который 100% будет пионерскими поделками, потому что невозможно написать нормальную новую БД, не будучи в состоянии осилить РСУБД и SQL.
Это как постреляционные СУБД. Вроде они есть, но на самом деле их нет - они продаются исключительно единичным заказчикам, паровозом вместе с софтом, который купили бы в любом случае, даже если бы он использовал хранилище в плоских файлах в виде компилируемых исходников, а данные бы туда сохранялись кодогенератором. Типа специализированного медицинского софта или там какого-нибудь "ПО для управления ДНК-секвенсором"
Скажите, это что за новая шиза в последнее время? Т.е., оно понятно, что SQL не обязательно нужен для задач типа "храним список пользователей и их мессаг на форуме", поэтому быдло-веб-пхп-программерам РСУБД, реляционнная алгебра и SQL кажется специальным садизмом по отношению к ним со стороны высоколобых энтерпрайз-коллег и маркетинговой дурью.
Но даже без этого начинается какая-то бредовая движуха, толкают какие-то говно-key-value db, какие-то hadoop, couchdb, cassandra и прочий трэш, который 100% будет пионерскими поделками, потому что невозможно написать нормальную новую БД, не будучи в состоянии осилить РСУБД и SQL.
Это как постреляционные СУБД. Вроде они есть, но на самом деле их нет - они продаются исключительно единичным заказчикам, паровозом вместе с софтом, который купили бы в любом случае, даже если бы он использовал хранилище в плоских файлах в виде компилируемых исходников, а данные бы туда сохранялись кодогенератором. Типа специализированного медицинского софта или там какого-нибудь "ПО для управления ДНК-секвенсором"
no subject
no subject
no subject
no subject
Хотя я вот то же самое сделаю, если не смогу sqlite заставить понимать мои запросы.
no subject
> или там какого-нибудь "ПО для управления ДНК-секвенсором"
Исключительно грамотное применение инструмента. SQL туда можно прикрутить, НО ЗАЧЕМ??? Смысла нет никакого.
no subject
no subject
P.S. эти БД возникли в ответ на необходимость хранения неструктурированной информации, часто в распределенной среде. у них есть свои варианты использования, не все в оперднях использовать
no subject
no subject
no subject
Только не был доступен тогдашним советским наколенникам :-)
no subject
no subject
no subject
no subject
1980 - dBase II под CP/M-80 ( http://ru.wikipedia.org/wiki/DBase )
1986 - первый стандарт языка SQL ( http://ru.wikipedia.org/wiki/Sql )
Т.е. безотносительно к советским наколенникам - по факту SQL на персоналках не было, и вообще он был доступен не всем.
no subject
no subject
no subject
Разумеется, выть на всех углах «SQL не нужен» — это как бы признак неадеквата, да, но это не означает, что всё должно быть SQL.
no subject
всякие фейсбуки, твитеры и прочие гуглы поднимают buzz, а остальные подхватывают
no subject
в других случаях оно кагбе нафик не нужно, но все верят, что у них будет хайлоад.
карго-культ, вообщем.
no subject
no subject
no subject
no subject
no subject
no subject
А то ж, я тоже собрался его пользовать, вот и думаю,
не напорюсь ли на какое некрасивое...
no subject
Я чуть помоложе буду, поэтому, я на нём
только мелкую полутестовую фигню долбил чуток.
no subject
чо-то я не так делаю и у меня такой запрос не работает
no subject
no subject
У меня, вроде, такого не будет.
no subject
2. Может захотеться хранить иерархических данных без необходимости ходить по ним руками и при этом не держать данные в памяти целиком (из-за размера).
no subject
no subject
или, там, фишка таких баз - schemaless. т.е. никакого "проектирования" таблиц и зависимостей. понадобилось - вкрутил.
такие штуки не рассматриваете?
no subject
Да и с запросами не совсем понятно, хотя с LINQ в последнее время с этим проще.
no subject
например, у тебя хранилище "отчеты". и ты валишь туда отчеты, естественно. не важно, причем, это xml файлы, или некие объекты, построенные по этим xml файлам.
у тебя есть индекс, который выгребает из хранилища "отчеты" нечто, у чего есть тег <balance>. ты это нечто обрабатываешь в "виде" и выплевываешь клиенту.
через год тебе говорят: товарищ, теперь отчеты будут еще в xls файлах. ты говоришь ок, и дописываешь в свой индекс (а он руками пишется на языке разработки) код, который теперь проверяет на xml/xls и в первом случае, работает по старинке, а втором парсит xls файл, находит ячейку со значением balance и индексирует твой объект по значению, например, той ячейки, которая справа от этой ячейки.
соответсвенно в "виде" допиливаешь вариант обработки xls файла. теперь у тебя в хранилище "отчеты" совершенно разные штуки лежат, а выгребаются точно также.
как-то так. отличий очень много, на самом деле. всего не распишешь, но у этого гавна есть право на жизнь.
no subject
База данных - это на самом деле намного проще, чем все эти файловые хранилища, особенно с современными ORM-мами.
no subject
1. Тот, который Вы обозначили. Я бы назвал его "фактор PHP". Пэхапе - редкое уёбище, но в него очень просто въехать и потому оно популярно в народных массах. mysql без транзакций - та же жуть, но победное его шествие нельзя игнорировать. в программирование вброшены огромные массы неумелых людей, отсюда востребованы любые корявые, но простые вещи.
2. Тот, в который Вы не верите. У нас на первом Четверге в DZ был рассказ о том, как в Яндексе был введён в продакшн map-reduce style обсчёт статистики, почему он был введён и почему SQL в этом месте не подходит. Коротко: потому что на статистике не нужна ни интегрити, ни гарантия сохранности данных. При этом мап редьюс даёт линейную (практически проверено) масштабируемость.
Насчёт сырости - вторым выступлением у нас был Микрософт, который в рамках azure продаёт доступ к key/value db, при этом, на секундочку, предлагает SLA. Лично свою руку я на отсечение не дам, но я очень сомневаюсь, что Микрософт подпишется под SLA, если технология сыра.
no subject
Вот написание ХОРОШЕГО компилятора для ОБЩЕЦЕЛЕВОГО ЯП - это другой вопрос. (И то - с появлением JVM перестало быть проблемой.) А написание компилятора для DSL должно быть в колоде каждого серьёзного разработчика одной из боевых карт.
Ну и всё остальное тоже.
Вы не видели evernote? За разработкой этого проекта стоит Пётр Квитек. Он написал ОО СУБД, которая лежит в основе сервиса, примерно за три месяца.
Жопа в том, что для современного русского программера всё это - вещи от бога, которые простой чел сделать не может, можно только купить в америце. Деградировала профессия. :(
no subject
no subject
Этот подход бесит привыкших к порядку, но он очень жизнеспособен.
Если не хранить так банковские транзакции. :)
no subject
То что map-reduce для некоторого подмножества задач подходит сильно лучше, чем извращаться с реляционными базами это, само собой, факт.
Я тут, закопавшись в своих бухгалтериях и прочих подсчетах до копейки каждой позиции, просто ни разу не сталкивался с задачами, где допустимо отсутствие ACID.
no subject
no subject
no subject
no subject
no subject