2016-06-07 4 views
0

Я создаю базу данных, и мне нужна помощь с дизайном.Дизайн базы данных с данными поиска

Моя таблица будет выглядеть следующим образом:

id 
request_employee_id 
request_menu 
request_submenu 
request_qty 
send_employee_id 
notify_employee_id 

Каждый запрос имеет добавить еще вариант. Например:

Запрос меню

id - 1 | Desc - Pencil 
id - 2 | Desc - Pen 
id - 3 | Desc - Eraser 
id - 4 | Desc - Marker 

В зависимости от выбранного меню Запрос будет иметь различные опции подменю.

Запрос Submenu

id - 1 | Desc - Yellow HB 
id - 1 | Desc - Black HC 
id - 2 | Desc - Blue Ink 
id - 2 | Desc - Black Ink 
id - 2 | Desc - Red Ink 
id - 3 | Desc - NULL 
etc... 

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

Реквестер может выбрать послать сотрудник X и добавить больше сотрудников, чтобы отправить как и отправить сотрудник Y и сотруднику W.

Реквестера может уведомить сотрудник Z о запросе и добавить больше сотрудников к работнику уведомления T и работник Y.

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

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

Или используйте множественное соединение с базой данных, чтобы получить: все меню из каждого запроса, другое соединение и запрос для всех send_employee по запросу, другое соединение для notify_employee по запросу. В конце я буду иметь как 7 разных соединений, так и оператор SQL select для сообщения одного запроса.

Примечание: я возобновляю стол, у меня также есть UOM по запросу, который будет попадать по той же проблеме, что и сотрудники. Каждый запрос может иметь кратность UOM по меню. Eaches, Bag, Cases и т. Д.

Каким будет лучший дизайн для обработки такого сценария.

Спасибо

ответ

0

Это может быть просто так:

CREATE TABLE tbl_Request(
    Request_ID INT IDENTITY(1,1) PRIMARY KEY, 
    Employee_ID INT NOT NULL, 
    Request_DT DATETIME NOT NULL, 
    Closed_Dt DATETIME 
); 
GO 
CREATE TABLE tbl_Category(
    Category_ID INT IDENTITY(1,1) PRIMARY KEY, 
    Category_Name VARCHAR(32) NOT NULL 
); 
GO 
CREATE TABLE tbl_Item(
    Item_ID INT IDENTITY(1,1) PRIMARY KEY, 
    Category_ID INT NOT NULL, 
    Item_Name VARCHAR(32) NOT NULL 
); 
GO 
CREATE TABLE tbl_Request_Details(
    Request_ID INT NOT NULL, 
    Item_ID INT NOT NULL, 
    Quantity DECIMAL NOT NULL 
); 
GO 
+0

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

+0

Привет Слава, спасибо за ваш ответ. Затем, когда я визуализую отчет, у меня будут множественные объединения для запроса пользователя, отправьте пользователя и сообщите пользователю, что это будет 3 присоединения к таблице сотрудников. Это правильно ? – user3216926

+0

Это правильно. Это кажется неэффективным, но нормализация значительно снижает объем данных, что уменьшает количество ввода-вывода для получения этих данных. И, как вы, наверное, знаете, I/O дороже процессора. Это означает, что ваш отчет будет работать быстрее. Однако, если вы хотите сделать ТОЛЬКО отчет об этом, тогда вы можете создать хранилище данных с таблицей «Запросить сведения» в виде таблицы фактов и запросов, категорий, элементов, сотрудников как размеров. –

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