Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Совет по структуре таблиц и запросу

396
03 февраля 2012 года
SibBear
223 / / 27.07.2006
некое подобие информационного сайта. Есть 2 основных типа страниц "новости" и "статьи", которые особо ничем не отличаются кроме названия.
Что хочу сделать. Вместо 2х таблиц в базе сделать одну, и просто добавить поле type.
Тогда я смогу в любой момент добавить 3й, 4й, 5й тип страниц, не создавая таблиц.

В этом есть смысл?

Дальше все поля "описание", "краткое", "картинка" вынести в отдельные таблицы, т.к. если картинки допустим нет, поле пустое, а это не есть хорошо.
Но тогда во всех этих табличках нужно добавлять кроме id еще 2 ключа parent_id и parent_type..
снова много полей...
12
04 февраля 2012 года
alekciy
3.0K / / 13.12.2005
Цитата: SibBear

В этом есть смысл?


В зависимости от цели которую ты хочешь достичь можно дать два диаметрально противоположных ответа. Так что определись с целью.

Цитата: SibBear

Дальше все поля "описание", "краткое", "картинка" вынести в отдельные таблицы, т.к. если картинки допустим нет, поле пустое, а это не есть хорошо.
Но тогда во всех этих табличках нужно добавлять кроме id еще 2 ключа parent_id и parent_type..
снова много полей...


Таблицы или таблицу? О_о
Вообще поля (атрибуты) можно просто вынести в одну отдельную таблицу. И даже type то атрибут который можно держать не в поле, а в значении (т.е. не column, а row).

Вообще вся схема легко ложится в 3 таблицы. page - в ней страницы (новость, статьи), attribute - свойства страницы (описание, краткое) и page_attribute - линковочная таблица многие-ко-многим минимум с 3 полями: первичный ключ из page, первичный ключ из attribute и со значением атрибута. В общем EAV (http://en.wikipedia.org/wiki/Entity–attribute–value_model).
В зависимости от условий и задачи тут еще огромные возможности для модификации данной схемы.

10
04 февраля 2012 года
Freeman
3.2K / / 06.03.2004
Вообще, "описание", "краткое", "картинка" и прочее, если применимы ко всем типам страниц, можно хранить и полями -- накладные расходы на хранение null минимальны, и пустого места они не занимают. DBF остался в прошлом веке, слава богу.

А к трём таблицам можно свести любую задачу. Главное, чтобы потом не пришлось плакать от рутины.
12
04 февраля 2012 года
alekciy
3.0K / / 13.12.2005
Можно и полями. Но лично я подобную практику использую только в случае если уверен, что это приносит профит на конкретное задаче в виде увеличения производительности. В остальных же случая считаю, что разделяя атрибуты по двум "сущностям" (столбцы и строки) мы теряем на удобстве сапорта кода. Потому что приходится поддерживать две "ветки" кода. Для экономии ресурсов можно использовать гибридный вариант, атрибуты по прежнему хранятся в строках, но их значения в столбцах. Количество столбцов равно количеству типов данной СУБД.
1
05 февраля 2012 года
kot_
7.3K / / 20.01.2000
Цитата: Freeman
Вообще, "описание", "краткое", "картинка" и прочее, если применимы ко всем типам страниц, можно хранить и полями -- накладные расходы на хранение null минимальны, и пустого места они не занимают. DBF остался в прошлом веке, слава богу.

А к трём таблицам можно свести любую задачу. Главное, чтобы потом не пришлось плакать от рутины.


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

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог