2013-04-20 4 views
1

У меня есть 2 вопроса относительно проекта. Буду признателен, если я получу разъяснения по этому поводу.Вопросы проектирования баз данных

  1. Я разлагаюсь Адрес в отдельные лицо, разбив до мельчайших единицы. Адреса Bur повторяются в нескольких таблицах. Подобные поля адреса находятся в таблице Client, а также таблице Employee. Если мы отделяем адрес в отдельную таблицу с только полем связи

    Для примера

  2. Создайте ADDRESS таблицу со следующими атрибутами:

    • ENTITY_ID (Это может быть сотрудник ID (Домашний адрес) или идентификатор клиента (адрес офиса))
    • Единица
    • Строительство
    • Street
    • Местность
    • Город
    • государственный
    • Страна
    • Zipcode
  3. Удалить все поля адреса из Employee таблицы и Client таблицы

Мы можем получить адрес, получив идентификатор employee и со ссылкой на таблицупо адресу

Какой подход лучше? Наличие полей адреса во всех таблицах или отдельных, как показано выше. Любые мысли, по которым дизайн лучше?

+1

проверить это: http://stackoverflow.com/questions/6576442/should-user-and-address-be-in-separate-tables – passion

ответ

1

Разделительный адрес в отдельную таблицу является лучшим дизайнерским решением, так как это означает, что любая логика проверки db-стороны и т. Д. Должна поддерживаться только в одном месте.

3

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

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

A. Использование одной таблицы

Имя таблицы --- АДРЕС

имена столбцов

  1. серийный номер (уникальный идентификатор или первичный ключ)
  2. Клиент/ID сотрудника
  3. Адрес.

B.Использование двух таблиц

Имя таблицы --- CLIENT_ADDRESS

имена столбцов

  1. серийный номер (уникальный идентификатор или первичный ключ)
  2. ID клиента (внешний ключ к таблице клиентов)
  3. Адрес.

Имя таблицы --- EMPLOYEE_ADDRESS

имена столбцов

  1. серийный номер (уникальный идентификатор или первичный ключ)
  2. ID клиента (внешний ключ к таблице сотрудников)
  3. Адрес.

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

Также есть одно предложение из моего опыта

Добавьте пять столбцов в каждый стол.

  1. CREATED_BY (Кто создал эту строку означает пользователь приложения)
  2. CREATED_ON (в какое время и дата строки таблицы была создан)
  3. MODIFIED_ON (Кто изменил эту строку означает пользователь из применение)
  4. MODIFIED_BY (В какое время и дата строка таблицы была изменена)
  5. DELETE_FLAG (0 - удаленные и 1 - Активный)

Т он объясняет это с точки зрения большинства разработчиков: ваш клиент может в любое время потребовать записи любого периода времени. Итак, если вы на самом деле уничтожаете, тогда для вас это будет серьезной ситуацией. Поэтому каждый раз, когда пользователь приложения удаляет запись из gui, вы должны установить флаг как 0, а не удалять его практически. Значение по умолчанию равно 1, что означает, что строка все еще активна.

На время поиска вы можете выбрать с условием, где, как этот

select * from EMPOLOYEE_TABLE where DELETE_FLAG = 1; 

Примечание: Это предложение из моего опыта. Я вовсе не принуждаю вас принять это. Поэтому, пожалуйста, добавьте его в соответствии с вашим требованием.

ТАКЖЕ таблицы, которые не имеют какой-либо значимой цели, не нуждаются в этом.

Смежные вопросы