Форум PHP программистов > О нормализации

[ Поиск ] - [ Пользователи ] - [ Календарь ]

T1grOK

7.02.2012 - 11:00

Я вот призадумался стоит ли "до конца" нормализовать базу данных или же наоборот денормализовать.
1) Есть база данных фильмов. При полной нормализации фильм-жанр будет состоять из трех таблиц:
- фильмы;
- жанры;
- фильмы-жанры.
То есть чтобы изъять информацию о фильме надо получить идентификатор фильма из "фильмы", потом из "фильмы-жанры" выдернуть идентификаторы жанров и в последнюю очередь получить названия жанров из "жанры".

2) В случае денормализации:
- фильмы(ид жанров в отдельном поле через запятую)
- жанры
Здесь получается получаем запись из "фильмы" и сразу можем получить названия жанров из "жанры" по идентификаторам жанров.

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

Кстати, неоднократно встречался в проектах, когда используется подобная денормализация.

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

P.S. Вроде сам и не новичок, но порой закрадываются сомнения.

Спустя 36 минут, 8 секунд (7.02.2012 - 10:36) inpost написал(а):

T1grOK
Скорость не теряется от лишнего ПРОСТОГО запроса. Ты гораздо больше потеряешь от всяких костылей вроде LIKE, а потом столкнёшься с новыми проблемами и лепить будешь новые костыли.

Записи через запятую: 2,15,25,1115.
WHERE LIKE '%1%' ? ты уверен, что найдет именно нужную запись?

Спустя 58 минут, 59 секунд (7.02.2012 - 11:35) alexbel2404 написал(а):

Цитата (inpost @ 7.02.2012 - 11:36)

да кстати, как победить такую ситуацию с like и перечислением в поле? в dle так организованы отношения поста к категориям.

Спустя 15 минут, 1 секунда (7.02.2012 - 11:50) inpost написал(а):

alexbel2404
Скорее всего регулярным выражением., а это ещё тяжелее будет.
Или в логике в обязательном порядке ставить запятые в начале и в конце:
,1,2,3, - вот полный вид строки. А при выборке LIKE '%,1,%' . И вообще, если они не умеют нормально организовывать структуры, то смысл в них работать?

Спустя 1 минута, 17 секунд (7.02.2012 - 11:51) inpost написал(а):

alexbel2404
У хлебных крошек есть несколько путей, и твой вариант кажется полной гадостью, который ты сказал в DLE. Может быть это не в ядре, а просто криворукий модуль, сделанный другими людьми?

Спустя 23 минуты, 45 секунд (7.02.2012 - 12:15) alexbel2404 написал(а):

Цитата (inpost @ 7.02.2012 - 12:51)

нет, это изначально сделано так. Ну переходить на другой движок уже не хочется с таким то онлайном и количеством страниц. Приходиться пилить этот)

Спустя 4 минуты, 53 секунды (7.02.2012 - 12:20) Nikitian написал(а):

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

Спустя 18 секунд (7.02.2012 - 12:20) caballero написал(а):

Цитата

Нормализация или денормализация

скажем так, нормализация в разумных пределах. Причем для мускула этот предел гораздо ниже чем для промышленных СУБД.

Спустя 1 час, 5 минут, 27 секунд (7.02.2012 - 13:25) T1grOK написал(а):

Цитата (inpost @ 7.02.2012 - 08:50)

Скорее всего регулярным выражением., а это ещё тяжелее будет.

Значительно тяжелее. Проверялось на таблице в 3000 тысячи записей. Замедление ощутимо даже невооруженным взглядом.

Спустя 1 минута, 46 секунд (7.02.2012 - 13:27) T1grOK написал(а):

Цитата (inpost @ 7.02.2012 - 07:36)

Ты гораздо больше потеряешь от всяких костылей вроде LIKE, а потом столкнёшься с новыми проблемами и лепить будешь новые костыли.

Убедил. Благодарю.

Спустя 1 час, 47 минут, 7 секунд (7.02.2012 - 15:14) alexbel2404 написал(а):

получается такого вида запрос

SELECT COUNT(*) as count FROM dle_post WHERE `category` REGEXP '\b1\b'

Так же просто выполнял запрос

SELECT '17,11,8,1' REGEXP '\b1\b';

Оба запроса ничего не возвращают, хотя ошибок не выдает.

Спустя 10 минут, 40 секунд (7.02.2012 - 15:25) alexbel2404 написал(а):

решил через 3ое ИЛИ

Спустя 7 минут, 25 секунд (7.02.2012 - 15:32) Winston написал(а):

alexbel2404
Попробуй так

SELECT * 
FROM  `table` 
WHERE `field` REGEXP  '[[:<:]]Здесь_Впиши_число[[:>:]]'

Спустя 6 минут, 34 секунды (7.02.2012 - 15:39) alexbel2404 написал(а):

Цитата (Winston @ 7.02.2012 - 16:32)

alexbel2404
Попробуй так

SELECT * 
FROM  `table` 
WHERE `field` REGEXP  '[[:<:]]Здесь_Впиши_число[[:>:]]'

Ага, работает. Спасибо, но через like вроде чутка побыстрее, как мне показалось. Ну да ладно, так компактнее и красивее, а memcache спасет от нагрузок на БД)

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Быстрый ответ:

Здесь расположена полная версия этой страницы.