|
|
|
Нужнали Иерархия
|
|||
|---|---|---|---|
|
#18+
Здраствуйте, разъясните плиз одну непонятную для меня вещь: есть у меня БД (мой курсовой проект). В ней есть такие таблицы: 1.Актер 2.Режиссер-постановщик(спектакля) 3.Художник по костюмам 4.Композитор(пишет музыку к спектаклю) 5.Автор(пьесы) Правильно ли будет создать иерархию и объеденить их загнав в одну таблицу-Служащие? У меня получается, что всех таблиц атрибуты будут одинаковы, но сами они (таблицы) будут связана с разными таблицами. И еще насколько правильно выделять таблицу если в ней планируется храниться 1-5 записей. Извените если вопрос глупый просто книг по проектированию в наших магазинах хороших нет, так что посмотреть негде %( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2008, 21:14 |
|
||
|
Нужнали Иерархия
|
|||
|---|---|---|---|
|
#18+
Иерархия тут не при чем. Это сверхстандартная задача, которая имеет три основных решения: 1. Держать информацию в одной общей таблице (добавив поле "тип сотрудника") 2. Держать информацию в разных таблицах 3. Держать общую информацию в общей таблице, а специфическую - во вспомогательных, ссылающихся на основную как 1:1. Выбор того или иного варианта опирается прежде всего на операции, которые будут производиться с этими данными. Если существует много общих операций - скажем, "добавить режиссера" ничем не отличается от "добавить уборщицу" - логично иметь одну таблицу. Если существует много различных операций - резонно иметь разные таблица. Если существует много того и другого.... ну Вы поняли :) Чтобы окончательно все запутать, стоит упомянуть, что можно делать не только таблицы, но и представления (view). Скажем, во втором варианте делаем объединяющий view с триггерами instead of - и получаем практически третий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 01:54 |
|
||
|
Нужнали Иерархия
|
|||
|---|---|---|---|
|
#18+
Пожалуй, любую классификацию можно естественным или искуственным путём свести к единой вершине. В конце концов все объекты в ЭВМ являются массивами байтов. Если в твоей задаче фигурирует класс Служащие, то можно подумать о том, как его удобно для использования представить в БД, если такого класса нету, т.е. он не играет ни какой роли ни в одной из процедур, то можно и не думать об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 05:15 |
|
||
|
Нужнали Иерархия
|
|||
|---|---|---|---|
|
#18+
Если все ТОЛЬКО так (что маловероятно) 1.Актер 2.Режиссер-постановщик(спектакля) 3.Художник по костюмам 4.Композитор(пишет музыку к спектаклю) 5.Автор(пьесы) то вариант softwarer "Держать информацию в одной общей таблице (добавив поле "тип сотрудника")" годится как простой и работоспособный. Но если 1.Актер (снимается, пишет музыку, которая может использоваться в спектакле, участвет в написании сценария за пузырем водки с автором) 2.Режиссер-постановщик(спектакля) (еще и хореограф, так как штатный заболел) 3.Художник по костюмам (приглашен временно из соседнего тетра, работает по контракту) 4.Композитор(пишет музыку к спектаклю, по совместительству осветитель) 5.Автор(пьесы, он же директор театра) ... и т.д. и т.п. то надо сначало определиться с моделью предментной области. Рещение скорее всего будет не простым ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2008, 18:59 |
|
||
|
Нужнали Иерархия
|
|||
|---|---|---|---|
|
#18+
kmawЕсли все ТОЛЬКО так (что маловероятно) 1.Актер 2.Режиссер-постановщик(спектакля) 3.Художник по костюмам 4.Композитор(пишет музыку к спектаклю) 5.Автор(пьесы) то вариант softwarer "Держать информацию в одной общей таблице (добавив поле "тип сотрудника")" годится как простой и работоспособный. Но если 1.Актер (снимается, пишет музыку, которая может использоваться в спектакле, участвет в написании сценария за пузырем водки с автором) 2.Режиссер-постановщик(спектакля) (еще и хореограф, так как штатный заболел) 3.Художник по костюмам (приглашен временно из соседнего тетра, работает по контракту) 4.Композитор(пишет музыку к спектаклю, по совместительству осветитель) 5.Автор(пьесы, он же директор театра) ... и т.д. и т.п. то надо сначало определиться с моделью предментной области. Рещение скорее всего будет не простым Дык, эта.... Человек - ФИО, год рождения, etc, человекID Роль - имя роли, рольID Роль человека - человекID, рольID, роль_человекаID Потом, к нужным сущностям (спектакль, например) присоединяем нужные роли. Через еще одну таблицу Спектакль - название, даты, спектакльID Участник спектакля - спектакльID, роль_человекаID, участникID При необходимости можно расширять таблицу "Роль человека" дополнительными свойствами для различных ролей. Либо таблицу "Участник". В зависимости от того, к чему это расширение относится - к человеку или к спектаклю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2008, 20:30 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=35123064&tid=1543970]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
15ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 247ms |
| total: | 335ms |
| 0 / 0 |
