Как правильно создать эту базу данных SQLite?

Question

Я хочу создать базу данных в SQLite с двумя таблицами: Customer and Orders. У каждого Клиента может быть много ордеров; (Я понимаю, что это отношения «один ко многим»). Каждый заказ может иметь много «позиций» (позиция - это конкретный заказ для «элемента»), в дополнение к информации о кредитной карте, условиям и информации о доставке (информация о не-адресном типе). Мне нужна возможность найти все заказы для любого конкретного клиента, но не нужно искать клиента по заказу.

Это то, что я до сих пор для клиента таблицы:

[db executeUpdate:@"CREATE TABLE IF NOT EXISTS CustData (" 
"BUS_NAME TEXT PRIMARY KEY NOT NULL, " 
"EMAIL TEXT, " 
"PHONE TEXT, " 
"SHOP_NAME TEXT, " 
"SHOP_ADDR1 TEXT, " 
"SHOP_ADDR2 TEXT, " 
"SHOP_CITY_STATE TEXT, " 
"SHOP_ZIP TEXT, " 
"SHIP_NAME TEXT, " 
"SHIP_ADDR1 TEXT, " 
"SHIP_ADDR2 TEXT, " 
"SHIP_CITY_STATE TEXT, " 
"SHIP_ZIP TEXT, " 
"NOTES TEXT)"]; 

Это то, что у меня есть для заказа стола:

[db executeUpdate:@"CREATE TABLE Orders (" 
"CUST_ID TEXT REFERENCES CustData, " 
"ORDER_NBR TEXT, " 
"SALES_NAME TEXT, " 
"CREDIT_CARD TEXT, " 
"EXP_DATE TEXT, " 
"CID TEXT, " 
"NOTES TEXT, " 
"PCS INTEGER, " 
"PATTERN TEXT, " 
"STYLE_NAME TEXT, " 
"PRICE DECIMAL)" ]; 

PCS, шаблон, STYLE_NAME и цены считаются "позиции".

Мой вопрос: это правильный способ определить эти таблицы в отношении «позиций» или есть лучший способ?

Answer 1

Неверная ваша конструкция для позиций.

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

В приведенном вами дизайне это означало бы разделение PCS, Pattern, Style_Name и Price на таблицу позиций вместе с Order_Nbr (если этого достаточно для идентификации заказа), либо Cust_ID и Order_Nbr.

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

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