Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Вопрос по проектированию, Разделение семантически однородных сущн. 
:(
    Опции темы
mus
Дата 24.3.2009, 22:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 80
Регистрация: 22.5.2005

Репутация: нет
Всего: 1



Представим, что есть фирма, которая работает с физическими и юридическими клиентами, которые разделены лишь условно. Функционально на сайте они имеют одни и те же права и функции, разнятся лишь атрибуты.
Вопрос - как целесообразней проектировать базу - с двумя таблицами (fiz_user и ur_user) и там уже конкретно указывать у кого какие атрибуты или делать одну таблицу с общими атрибутами, а разнящиеся атрибуты раскидать по другим таблицам? Иными словами - как организовать что-то вроде наследования + полиморфизм на уровне БД?..
PM MAIL   Вверх
Gluttton
Дата 25.3.2009, 00:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Начинающий
***


Профиль
Группа: Завсегдатай
Сообщений: 1170
Регистрация: 28.8.2008
Где: Феодосия

Репутация: 10
Всего: 54



Так как опыта создания комеческих БД у меня нет, поэтому изложеное ниже - голая теория.

Глубоко убежден, что лучше "разносить" физических и юридических лиц по разным таблицам. Я не знаю специфику конкретной задачи, но исходя из специфики предприятия на котором работаю я, разница (набор атрибутов) между физическими и юридическими лицами может быть существененна. Совершенно не существенная потеря в нормализации даст выигрыш в интуитивно понятном сопровождении БД.

А если 
Цитата

разнящиеся атрибуты раскидать по другим таблицам

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

Лица:                Свидетельство платильщика НДС:
ID ---------------- ID
    \  1             1  
     \
      \ 1            1  Паспорт:
       ---------------ID

А в книжках пишут, что наличие связей 1:1 - "вынесение атрибута в сущность" (там пишут умными словами  smile , но суть такая) и это результат неудачного проектирования (речь идет о физическом, а не логическом и концептуальном).

Вот такой вариант будет правильнее 

Юр. Лица:                     Физ. Лица:
ID                                   ID
SP_NDC                          P

Можно и вот так вот даже сделать  smile :

Лица:
ID
SP_NDC
P

P.S. Щас подтянуться "пятизвездочные" и раскажут что по чём  smile .

Это сообщение отредактировал(а) Gluttton - 25.3.2009, 00:50


--------------------
Слава Україні!
PM MAIL   Вверх
aleksh
Дата 25.3.2009, 02:35 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 609
Регистрация: 8.7.2008

Репутация: 2
Всего: 13



давно не был на форуме, ибо с трудом улавливаю суть, вот например -- можно конкретней о 
Цитата(mus @  24.3.2009,  22:52 Найти цитируемый пост)
наследования + полиморфизм на уровне БД
?

по сути -- а возможно сделать так: таблица для физиков, таблица для юриков, и таблица атрибутов, причем в таблице атрибутов что-то навроде (ключ, название, ... свойства-характеристики, "отношение"), где "отношение" числовое поле с 0 - общий для физ и юр атрибут, 1 - только для физ, 2 - только для юр. в таблицах клиентов прописывать ключи к таблице атрибутов, причем можно будет простым запросом как отсекать лишнее, так и дополнительно проверять корректность данных

PM MAIL   Вверх
Zloxa
Дата 25.3.2009, 09:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(mus @  24.3.2009,  22:52 Найти цитируемый пост)
Вопрос - как целесообразней проектировать базу - с двумя таблицами (fiz_user и ur_user) и там уже конкретно указывать у кого какие атрибуты или делать одну таблицу с общими атрибутами, а разнящиеся атрибуты раскидать по другим таблицам? 

Необходимо определиться как этот справочник будет использован
Цитата(mus @  24.3.2009,  22:52 Найти цитируемый пост)
Иными словами - как организовать что-то вроде наследования + полиморфизм на уровне БД?.. 

Не мешайте ряженку с компотом.

Объектная модель и реляционная модель - суть разные модели. Если объетная модель предназначена для описания особенностей одного объекта, то реляционная модель - для описания отношений множеств объектов. Все известные ныне гибриды, весьма ублюдочны и маложизнеспособны.

Это сообщение отредактировал(а) Zloxa - 25.3.2009, 10:07


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
DimW
Дата 25.3.2009, 11:46 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 2
Всего: 44



Цитата(Zloxa @  25.3.2009,  09:59 Найти цитируемый пост)
Не мешайте ряженку с компотом.

реальность такова что мешают и весьма успешно, но задачи эти разных уровней.
для инфо: http://ru.wikipedia.org/wiki/ORM
Но честно говоря я сам не очень верю в целесообразность данного подхода.
При попытке выяснить плюсы данного подхода: http://forum.vingrad.ru/forum/topic-229064...tml#st_0_view_0 ничего вразумительного получить не удалось, ибо добрая половина любителей объектного подхода не имеют представления о элементарных вещах и расценивают данный подход как избавление от "неудобств" реляционной модели.
PM MAIL ICQ   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Общие вопросы по базам данных"
LSD
Zloxa

Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:

  • вопросам по СУБД для которых нет отдельных подфорумов
  • вопросам которые затрагивают несколько разных СУБД (например проблема выбора)
  • инструменты для работы с СУБД
  • вопросы проектирования БД
  • теоретически вопросы о СУБД

Данный форум не предназначен для:

  • вопросов о поиске разлиных БД (если не понимаете чем БД отличается от СУБД то: а) вам не сюда; б) Google в помощь)
  • обсуждения проблем с доступом к СУБД из различных ЯП (для этого есть соответсвующие форумы по каждому ЯП)
  • обсуждения проблем с написание SQL запросов, для этого есть форум Составление SQL-запросов
  • просьб о написании курсовой, реферата и т.п., для этого есть Центр помощи или фриланс биржа
  • объявлений о найме специалистов, для этого есть раздел Объявления о найме специалистов

Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение. ;)


Полезные советы:

При написании сообщения постарайтесь дать теме максимально понятное название. В теме максимально подробно опишите проблему. Если применимо укажите: название базы данных и версии (MySQL 4.1, MS SQL Server 2000 и т.п.); используемых язык программирования; способа доступа (ADO, BDE и т.д.); сообщения об ошибках.

Для вставки кода используйте теги [code=sql] [/code].

Литературу по базам данных можно поискать здесь.

Действия модераторов можно обсудить здесь.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | СУБД, общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.0442 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.