gdskomar 08.02.2013 08:49 umodni7A626189

"
Объявляется набор авторов для работы над монографией "Суеверия и обычаи, бытующие среди простого народа относительно СУБД".
"
[ http://plumqqz.livejournal.com/346455.ht... ]

Recommended by: @komar, @proton
1. komar 08.02.2013 08:50 thinkpad

Не читал, но буду.

2. gdskomar /1 08.02.2013 08:51

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

3. kb 08.02.2013 08:51

Какого рода обычаи, интересно.

4. komargds /2 08.02.2013 08:56 thinkpad

Мне очень стыдно писать, будучи полным дилетантом.
(хотя все, что я когда-либо писал, я написал, будучи им)

5. komargds /2 08.02.2013 08:56 thinkpad

Олсо, я могу принести на работу диктофон и поговорить с архитектором. Потом передать материал в обработку.

6. gdskb /3 08.02.2013 09:17

приведу краткий список, что сразу приходит на ум, из заблуждений (кое-какие ещё и обычаи):
- рсубд это тормозно
- views это тормозно
- хранимки ненужны
- чем больше индексов — тем быстрее работает всё
- репликация заменяет бэкапы
- триггеры это идеально для описания бизнес-логики
- нормализованные схемы тормозят
- orm это хорошо
- sql это плохо
- локи? ненеслышали
- транзакции для лохов
- все рсубд работают одинаково — sql же!
- всегда, когда пишется софт, надо учитывать то, что его раз в месяц-два будут переносить с оракла на mysql, потом на постгрес, а потом обратно на оракл
- not null поля ограничивают полёт фантазии
- внешние ключи для слабаков, не умеющих сразу правильно писать
- explain plan? ненеслышали
- чем более выгоден план, тем быстрее выполняется запрос

7. komargds /6 08.02.2013 09:23 thinkpad

— Парсинг SQL тормозит.
— ACID не нужен.
— ACID тормозит.
— Нормализация? Не, не слышали.
— Как искать по массивам??777
— Как нам зделоть блог с тегами без монги?
— Схема базы — это плохо.
— Ынтыграцыи реляционок в язык не существует.
— ORM’ом можно сделать все то, что и на голом SQL’е (надо бы мне развернуть).

8. kbgds /6 08.02.2013 09:25 3b662f5e

годно, согласен

9. kbkomar /7 08.02.2013 09:25 3b662f5e

говно какое-то.

10. komarkb /9 08.02.2013 09:25 thinkpad

Естественно, половину же ты выдал.

11. gdskomar /10 08.02.2013 09:26

ну, прям половину — про блох с тегами точно, остальное же — не уверен.

12. kbkomar /10 08.02.2013 09:27 3b662f5e

в твоём списке только какое-то искажение того, что я писал. Впринципе четко показывает твоё восприятие.

13. kbgds /11 08.02.2013 09:27 3b662f5e

так в чем проблема? Будто люди не знают о связях, джойнах и прочих. Или в чём заблуждение? Я ведь не утверждал что это невозможно сделать.

14. komarkb /13 08.02.2013 09:29 thinkpad

— Джоины — это сложно и не нужно.

15. gdskb /13 08.02.2013 09:29

ну, там было не столько "невозможно", сколько "невозможно сделать быстро и нормализованно", или, скорее, "а как иначе, кроме хранения array of tags в таблице". Лень искать, проще забить.

16. kbkomar /14 08.02.2013 09:29 3b662f5e

я такое говорил? или кто-то так считает?

17. kbgds /15 08.02.2013 09:32 3b662f5e

нет, суть того, что я имел в виду в следующем: невозможно сделать отображение объектов в записи в таблице т.к. невозможно хранить вложенные документы, например. Уж про "невозможно сделать нормализованно" я точно не говорил.

Уж "как иначе кроме хранения array of tags" я точно не говорил, т.к. сам бы сделал внешнюю таблицу.

18. komarkb /16 08.02.2013 09:32 thinkpad

— Миграции в РСУБД — это пиздец-пиздец.

19. kbkomar /18 08.02.2013 09:33 3b662f5e

по поводу
- схема не нужна
- миграции не нужны

поддерживаю, те кто так считают — идиоты.

20. gdskb /19 08.02.2013 09:34

чо за миграции? Может я термина не знаю?

21. komargds /20 08.02.2013 09:36 thinkpad

Это когда схему меняешь.

22. komarkb /19 08.02.2013 09:36 thinkpad

ПИТОНОМЕШАЛКА
ЯЗЫКА ДИНАМИЗМ
ВИРТУАЛЬНОЙ МАШИНЫ
ПОЛИМОРФИЗМ

23. kbkomar /21 08.02.2013 09:36 3b662f5e

или данные

24. kbkomar /22 08.02.2013 09:37 3b662f5e

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

25. komargds /6 08.02.2013 09:37 thinkpad

> — хранимки ненужны
— Любые проверки на стороне БД не нужны.

26. gdskomar /21 08.02.2013 09:41

так это, а как же без миграций в этом смысле слова?

27. kbgds /26 08.02.2013 09:43 3b662f5e

некоторые считают, что нет схемы — значит нет миграций. (впринципе, в некоторых частных случаях они правы, например при добавлении nullable поля, но снова таки, есть нюансы)

28. komargds /26 08.02.2013 09:48 thinkpad

Я не говорил, что они не нужны. Я говорю о том, что в РСУБД это типа заебисто.
То ли дело в монге — нихуя делать не надо. только потом срач по всей базе собирай.

29. kbgds /6 08.02.2013 09:48

Кстати вот еще заблуждения:
- orm это плохо
- на голом sql всё делать гораздо проще

// как живой пример — point.im

30. komarkb /29 08.02.2013 09:48 thinkpad

Блять, ну не смешно нихуя же.

31. kbkomar /28 08.02.2013 09:49 3b662f5e

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

32. kbkomar /30 08.02.2013 09:50 3b662f5e

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

33. komarkb /32 08.02.2013 09:52 thinkpad

Главная проблема арца в том, что он мудак.

34. kbgds /6 08.02.2013 09:53 3b662f5e

ах да, еще одно заблуждение — если принято решение "писать на голом sql" (без orm) — значит будем строками хуячить sql

// это я про прекрасную (как пример) SQLAlchemy, которая отлично работает без ORM-модуля и позволяет легко динамически составлять SQL (кажется) любой сложности

35. komarkb /34 08.02.2013 10:21 thinkpad

Хотел рассказать про пгокамл/макаку, которые при компиляции ходят в БД и проверяют запросы на корректность, но подумал, чо слишком рак.

36. kbkomar /35 08.02.2013 10:24 3b662f5e

это очень круто, и как минимум в предачу решает проблему sql-инъекций (если при этом запретить как-то выполнять непроверенные запросы).

37. komarkb /36 08.02.2013 10:32 thinkpad

Это решает проблему дерганья не тех колонок.

38. kbkomar /37 08.02.2013 10:34 3b662f5e

ну, в том числе.

Do you really want to delete ?