gds
→ komar
08.02.2013 08:49 umodni7A626189
"
Объявляется набор авторов для работы над монографией "Суеверия и обычаи, бытующие среди простого народа относительно СУБД".
"
[ http://plumqqz.livejournal.com/346455.ht... ]
Не читал, но буду.
а самих суеверий и обычаев ты разве не наблюдал? Думал, присоединишься к авторскому коллективу.
Какого рода обычаи, интересно.
Мне очень стыдно писать, будучи полным дилетантом.
(хотя все, что я когда-либо писал, я написал, будучи им)
Олсо, я могу принести на работу диктофон и поговорить с архитектором. Потом передать материал в обработку.
приведу краткий список, что сразу приходит на ум, из заблуждений (кое-какие ещё и обычаи):
- рсубд это тормозно
- views это тормозно
- хранимки ненужны
- чем больше индексов — тем быстрее работает всё
- репликация заменяет бэкапы
- триггеры это идеально для описания бизнес-логики
- нормализованные схемы тормозят
- orm это хорошо
- sql это плохо
- локи? ненеслышали
- транзакции для лохов
- все рсубд работают одинаково — sql же!
- всегда, когда пишется софт, надо учитывать то, что его раз в месяц-два будут переносить с оракла на mysql, потом на постгрес, а потом обратно на оракл
- not null поля ограничивают полёт фантазии
- внешние ключи для слабаков, не умеющих сразу правильно писать
- explain plan? ненеслышали
- чем более выгоден план, тем быстрее выполняется запрос
— Парсинг SQL тормозит.
— ACID не нужен.
— ACID тормозит.
— Нормализация? Не, не слышали.
— Как искать по массивам??777
— Как нам зделоть блог с тегами без монги?
— Схема базы — это плохо.
— Ынтыграцыи реляционок в язык не существует.
— ORM’ом можно сделать все то, что и на голом SQL’е (надо бы мне развернуть).
годно, согласен
говно какое-то.
Естественно, половину же ты выдал.
ну, прям половину — про блох с тегами точно, остальное же — не уверен.
в твоём списке только какое-то искажение того, что я писал. Впринципе четко показывает твоё восприятие.
так в чем проблема? Будто люди не знают о связях, джойнах и прочих. Или в чём заблуждение? Я ведь не утверждал что это невозможно сделать.
— Джоины — это сложно и не нужно.
ну, там было не столько "невозможно", сколько "невозможно сделать быстро и нормализованно", или, скорее, "а как иначе, кроме хранения array of tags в таблице". Лень искать, проще забить.
я такое говорил? или кто-то так считает?
нет, суть того, что я имел в виду в следующем: невозможно сделать отображение объектов в записи в таблице т.к. невозможно хранить вложенные документы, например. Уж про "невозможно сделать нормализованно" я точно не говорил.
Уж "как иначе кроме хранения array of tags" я точно не говорил, т.к. сам бы сделал внешнюю таблицу.
— Миграции в РСУБД — это пиздец-пиздец.
по поводу
- схема не нужна
- миграции не нужны
поддерживаю, те кто так считают — идиоты.
чо за миграции? Может я термина не знаю?
Это когда схему меняешь.
ПИТОНОМЕШАЛКА
ЯЗЫКА ДИНАМИЗМ
ВИРТУАЛЬНОЙ МАШИНЫ
ПОЛИМОРФИЗМ
или данные
Учитывая все ваши ответы, хочу сказать спасибо. Я ошибался и признаю это.
Аргументированные ответы. Я сделал поспешные выводы и Вы вернули мне веру в ББ.
> — хранимки ненужны
— Любые проверки на стороне БД не нужны.
так это, а как же без миграций в этом смысле слова?
некоторые считают, что нет схемы — значит нет миграций. (впринципе, в некоторых частных случаях они правы, например при добавлении nullable поля, но снова таки, есть нюансы)
Я не говорил, что они не нужны. Я говорю о том, что в РСУБД это типа заебисто.
То ли дело в монге — нихуя делать не надо. только потом срач по всей базе собирай.
Кстати вот еще заблуждения:
- orm это плохо
- на голом sql всё делать гораздо проще
// как живой пример — point.im
Блять, ну не смешно нихуя же.
я думал ты приводил заблуждение, а не говорил от себя. Ну и живых примеров развода говна в монге не встречал, благо. Все лепят свои клиент-сайд схемы и прочее.
я серьезно смотрел на исходники point.im и плакал из-за того, что там чистый sql, как он лепится в строки, куски дублируются по всему проекту и так далее.
Главная проблема арца в том, что он мудак.
ах да, еще одно заблуждение — если принято решение "писать на голом sql" (без orm) — значит будем строками хуячить sql
// это я про прекрасную (как пример) SQLAlchemy, которая отлично работает без ORM-модуля и позволяет легко динамически составлять SQL (кажется) любой сложности
Хотел рассказать про пгокамл/макаку, которые при компиляции ходят в БД и проверяют запросы на корректность, но подумал, чо слишком рак.
это очень круто, и как минимум в предачу решает проблему sql-инъекций (если при этом запретить как-то выполнять непроверенные запросы).
Это решает проблему дерганья не тех колонок.
ну, в том числе.