2012-02-24 6 views
0

Неправильно ли реализовать супертип и подтип всем данным в базе данных? Мне нужен совет по этому вопросу, прежде чем перейти к этому направлению ...Последствия супертипа и подтипа

Например,

У меня есть эти таблицы как объекты, и они связаны между собой,

users 
pages 
images 

entities таблицу супертипе

entity_id  entity_type 
1    page 
2    page 
3    user 
4    user 
5    image 
6    image 

users стол

user_id  entity_id 
1   3 
2   4 

pages стол

page_id  entity_id 
1   1 
2   2 

images стол

image_id  entity_id 
1   5 
2   6 

здесь таблица на картуimages стол с entities столом, потому что некоторые изображения принадлежат определенной странице (возможно в блог сообщения, и т.д. в будущее),

map_entity_image стол

entity_id image_id 
1   1 
1   2 

так, я вставить строку в таблице entities, когда у меня есть страница, изображение, пользователь, и т.д., который будет создан.

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

В конце концов, это плохая структура?

или, может быть, я делаю супертип/подтип неправильно?

редактировать:

Я думаю, что entity должен иметь только эти данные,

entity_id  entity_type 
1    page 
2    page 

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

entity_id  entity_type 
1    page 
2    page 
3    user 
4    user 

Возможно, я ошибаюсь ...

EDIT:

так это вопрос, как я могу узнать, сколько изображений, прикрепленных к странице ид 1,

SELECT E.*, P.*, X.*,C.* 
FROM entities E 

LEFT JOIN pages P ON (P.entity_id = E.entity_id) 

LEFT JOIN map_entities_images X ON (X.entity_id = E.entity_id) 

LEFT JOIN images C ON (C.image_id = X.image_id) 
WHERE P.page_id = 1 

возвращается изображения.

+0

Как вы ожидаете использовать эти сущности-таблицы? Что это дает вам, что стандартный SQL на базовых таблицах не будет? Почему вы беспокоитесь об этом, когда у него нет видимых функций? –

+0

спасибо. пожалуйста, взгляните на мое редактирование. Благодарю. – laukok

+1

У вас может быть таблица изображений, на которую ссылаются как «страница», так и «комментарий». Вам не нужны дополнительные таблицы (при условии, что в каждом комментарии есть только одна ссылка на изображение), вам просто нужен столбец для хранения идентификатора изображения, и все работает! Если существует много-много отношений, вам нужна одна таблица пересечений «page-contains-image» с идентификатором страницы и идентификатором изображения и одна таблица «user-has-image» с идентификатором пользователя и идентификатором изображения. Будь проще! –

ответ

1

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

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

enter image description here


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

enter image description here

... но с таким количеством подклассов, которые я бы рекомендовал против этого (из-за потенциальной ремонтопригодности и проблем с производительностью). С другой стороны, если в будущем возможно добавлять новые подклассы, это может быть правильным решением (ENTITY_IMAGE автоматически «покрывает» все эти новые подклассы, поэтому вам не нужно вводить новую «ссылку», таблица для каждого из них).

BTW, есть 3 major ways для реализации иерархии категорий, каждая из которых имеет свой собственный набор компромиссов.

+0

Большое спасибо за ответ, Бранко.Я думаю, что я пошел бы на иерархию категорий, поскольку подклассы могут расти в будущем. FK в таблице изображений определенно является мертвой. вне темы - какую программу вы используете для рисования этих красивых диаграмм? :-) – laukok

+0

@lauthiamkok Microsoft Visio. Выберите «Модель диаграммы базы данных» при создании нового документа, нарисуйте диаграмму, экспортируйте ее в PNG, и вы готовы к загрузке в StackOverflow :) –

+0

большое спасибо, Бранко! :-) – laukok

0

Не совсем ответ на ваш вопрос, но то, что вы описываете, не то, что большинство модельеров будет называть «супертипом».

Это аналогично супер/подклассам в ООП. Супертип является генетическим объектом, и подтип является более специализированной версией общего объекта

Классический пример - транспортные средства. «Автомобиль» имеет общий набор атрибутов, таких как «владелец», «цена», «сделать», «модель». Неважно, будь то автомобиль, велосипед или лодка. Однако у автомобилей есть «колеса», «двери», «размер двигателя» и «тип двигателя», велосипеды имеют «количество передач» и «рельефный тип» (BMX, дорога и т. Д.), А лодки имеют «пропеллеры», , "паруса" и "каюты".

Существует два способа реализации этого.

Во-первых, есть «сворачивание», у вас есть одна таблица, которая содержит все общие атрибуты для «транспортного средства» плюс дополнительные аттрибуты для каждого типа транспортного средства.

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

+0

спасибо за ответ. возможно, я еще не понял это, сделав эти таблицы в супертип/подтип. Я пытаюсь реализовать это из ответа, данного в этом вопросе - http://stackoverflow.com/questions/9381261/an-image-table-to-serve-two-foreign-tables, может быть, вы можете сказать мне, как я могу работать От этого? Благодарю. – laukok