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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
можно, но будет говнокод, который потом кому-то годами вычищать, как сейчас в Сотмаркете
 

MiksIr

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

grigori

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

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Говнокод не зависит от нормализации/денормализации. Денормализация может быть убрана на уровень DBA.
Архитектура приложения завязана на структуру базы данных, бизнес-логика завязана на архитектуру приложения.
Вынести архитектуру базы на уровень DBA и абстрагироваться от нее в приложении так, чтобы менять бизнес логику без переработки структуры базы в общем случае невозможно. Менять живую денормализованную базу с 10 млн записей в таблицае, когда простой в 1 час стоит сто тысяч рублей, черезвычайно сложно. Это исторический факт.

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

MiksIr

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

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

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

fixxxer

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

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

fixxxer

К.О.
Партнер клуба
Архитектура приложения не завязана на структуру базы данных
Если уж говорить о настоящих хайлоадах - еще как завязана. Точнее, одно следует из другого.
 

MiksIr

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

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

MiksIr

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

fixxxer

К.О.
Партнер клуба
мне кажется, что база следует из архитектуры
База следует из архитектуры, а особенности архитектуры следуют из ограничений базы. Все связано :)

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

MiksIr

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

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

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

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

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

fixxxer

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

AnrDaemon

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

bazooka

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

PHP:
Сейчас мой каталог на join-ах вообще без кешей отдается меньше, чем за 0.1 сек.
Сварганил я базу без join забил вышеуказанным количеством данных, выборка из 4 запросов+вывод 0,0004 ;)
 
Сверху