Mysql Помогите понять нормализацию

[grigori]

можно, но будет говнокод, который потом кому-то годами вычищать, как сейчас в Сотмаркете

 

[MiksIr]

Говнокод не зависит от нормализации/денормализации. Не говоря уже о том, что эта денормализация (вернее поддержание ее актуальности) может быть убрана на уровень DBA.

 

[grigori]

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

Я понимаю разницу между кешированием и денормализацией, но в контексте этой темы - ее фактически нет. Т.е. если мы утверждаем, что денормализации быть не должно, а вот кеш - можно, то это бред.

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

 

[grigori]

Говнокод не зависит от нормализации/денормализации. Денормализация может быть убрана на уровень DBA.

Архитектура приложения завязана на структуру базы данных, бизнес-логика завязана на архитектуру приложения.
Вынести архитектуру базы на уровень DBA и абстрагироваться от нее в приложении так, чтобы менять бизнес логику без переработки структуры базы в общем случае невозможно. Менять живую денормализованную базу с 10 млн записей в таблицае, когда простой в 1 час стоит сто тысяч рублей, черезвычайно сложно. Это исторический факт.

я устал, это реально бред, отписываюсь

 

[MiksIr]

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

Архитектура приложения не завязана на структуру базы данных. Равно как бизнес-логика не завязана на архитектуру приложения. У вас, видимо, какое-то свое понимание термина "архитектура приложения", мне неведомое.

Вынести архитектуру базы на уровень DBA и абстрагироваться от нее в приложении так, чтобы менять бизнес логику без переработки структуры базы в общем случае невозможно.

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

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

 

[fixxxer]

Даже если вы храните копию данных 1 в 1 в кеше - это все-равно вторая копия данных, т.е. избыточность.

Да как угодно называй. Инвалидация кэша по всем зависимостям не делается просто. Это дополнительная логика в persistence layer, и однажды ее добавив, поддерживать надо везде. И такая поддержка будет несколько дороже стоимости аренды пары серверов.

С денормализацией та же история, но она, на самом деле, проще. С денормализацией не надо ловить баги инвалидации сложных зависимостей и мониторить hit-miss графики =)

 

[fixxxer]

Архитектура приложения не завязана на структуру базы данных

Если уж говорить о настоящих хайлоадах - еще как завязана. Точнее, одно следует из другого.

 

[MiksIr]

Да как угодно называй. Инвалидация кэша по всем зависимостям не делается просто. Это дополнительная логика в persistence layer, и однажды ее добавив, поддерживать надо везде. И такая поддержка будет несколько дороже стоимости аренды пары серверов.
С денормализацией та же история, но она, на самом деле, проще. С денормализацией не надо ловить баги инвалидации сложных зависимостей и мониторить hit-miss графики =)

Это крайний случай. Даже с денормализацией, хоть она и проще, можно наворотить такого, что потом получить кучу проблем из-за неконсистентности данных. И баги инвалидации там тоже можно огребсти. Ну так это можно любую идею утрировать и испоганить - не повод, что бы отказываться от идеи совсем.

Ну, а по поводу, почему "нормализация никогда нельзя", а "кеширование можно", что можно вынести из речей grigori, я так и не понял. Видимо ответ где-то зарыт в посте про лошадей и машин, но, увы, мне этот искрометный юмор недоступен =(

 

[MiksIr]

Если уж говорить о настоящих хайлоадах - еще как завязана. Точнее, одно следует из другого.

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

 

[AnrDaemon]

А что именно будем выбирать - это уже следующий шаг.

Поясните свою мысль, пожалуйста.

 

[fixxxer]

мне кажется, что база следует из архитектуры

База следует из архитектуры, а особенности архитектуры следуют из ограничений базы. Все связано

а по поводу, почему "нормализация никогда нельзя", а "кеширование можно", что можно вынести из речей grigori, я так и не понял

а это не ко мне вопрос, я такого не говорил

 

[MiksIr]

Поясните свою мысль, пожалуйста.

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

Например, выбор REST с отображением на клиентской стороне, и выдачей голых данных без оформления на серверной - это архитектурное решение. Какие данные будут передаваться и даже каким способом закодированные (xml, json) - это уже проработка ПО, оно не должно осуществляться на уровне архитектуры.

Архитектурный паттерн MVC - говорит о том, что у нас 3 слоя, и какой с каким взаимодействует. Архитектура ПО говорит, что для хранения персистентной информации мы используем СУБД. Но не говорит, как мы будем структурировать данные в этой СУБД.

Ну как я понимаю эту терминологию.

База следует из архитектуры, а особенности архитектуры следуют из ограничений базы. Все связано

Особенности СУБД, если быть совсем занудным. Это да, соглашусь. Но схемы данных, т.е. именно база данных - не влияет. Она влияет на уже на проработку функционала слоев.

 

[fixxxer]

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

 

[AnrDaemon]

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

 

[MiksIr]

Совершенно не о том. OSI была попытка создать стандарт.

 

[bazooka]

мне лень составлять все эти запросы

Да я знаю как составить все эти запросы, не вижу смысла каждый раз считать при миллионе сообщений, 100 тыс. тем и 10 тыс. юзеров.

Сейчас мой каталог на join-ах вообще без кешей отдается меньше, чем за 0.1 сек.

Сварганил я базу без join забил вышеуказанным количеством данных, выборка из 4 запросов+вывод 0,0004