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

Question

Я новичок в PHP/Базах данных ... Но я подбираю его довольно быстро. Я хотел бы попросить вас, ребята, довольно просто. Я хочу нормализовать свою базу данных и не уверен, как это сделать. Я понимаю концепцию, но вижу несколько способов сделать это. Рисунок. Я бы попросил людей с некоторым опытом.

Вот моя база данных (2 таблицы до сих пор): Бренды Продукты

***Brands Breakdown:*** 
1 id   int(6) 
**Note:** Above, I will probably use 4-Letter codes for each brand instead of primary/int/auto. 
2 name   text 
3 logo   varchar(20) 
4 phone   varchar(20) 
5 website  varchar(30) 
6 contact_name text 
7 contact_number varchar(20) 
8 contact_email varchar(30) 
9 warehouse  varchar(20) 
10 pricing   varchar(15) 
11 bio    varchar(300) 

***Products Breakdown*** 
id (INT(6)/Auto_Increment) 
brand (This is where I'll insert the four letter code for brand) 
category (e.g. Brakes) 
subCategory (e.g. Brake Rotors) 
details (e.g. Drilled and Slotteed 'Razr') 
sku (Part #) 
minYear 
maxyear 
make (e.g. Subaru) 
model (e.g. Impreza) 
subModel (e.g. WRX STi) 
description (Paragraph on part describing it) 

specs (I imagine this can be expanded on. need cells somewhere for sizes/colors/engine codes/etc.) 

msrp 
jobber 
price 
cost 
weight (of part) 
warehouse (Could be moved to brand's table) 
image (URL of image for the part) 

---

Так что мой главный вопрос: Должен ли я сделать каждый бренд имеет там собственную таблицу, подобную моей нынешней «продукции ' Таблица? или есть таблицы категории? «подкатегории»? Как вы, ребята, нормализуете эти данные?

Я хотел бы иметь прочную базу данных, пока я изучаю этот материал, поэтому я узнаю правильный путь. Любой совет будет принят во внимание.

UPDATE: Для тех, кто попадается этот вопрос, который пытается научиться строить свои базы данных, одна из основных вещь, которую я не знал, когда я спросил, это было что-то под названием «cardinality». Изучите эту тему и узнайте, как применить ее к вашим схемам базы данных!

Answer 1

Не заставляйте каждый бренд иметь собственный стол. Это не нормализация, это разделение. Не делайте этого, пока ваша база данных не станет очень большой.

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

Вот мое предложение.

Переименуйте свой бренд-стол. Назовите его «Производитель» и разделите его на два, для производителя и контакта.

Производитель:

mfrid (your four letter code, primary key) 
mfrname   text 
mrflogo   varchar(20) 
mfrwebsite  varchar(30) 
mfrphone   varchar(20) 
warehouse  varchar(20) 

Контакт:

mfrid (four letter code) (part of primary key) 
contactid (autoincrement) (part of primary key) 
contact_name text 
contact_number varchar(20) 
contact_email varchar(30) 
bio    varchar(300) 

Почему "ценообразование" атрибут производителя? Что вы подразумеваете под «ценой»? Разве это не атрибут отдельной части?

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

SKU:

sku (your stock-keeping unit number, primary key). 
mfrid (maker of the PART, not the vehicle in which it fits, foreign key to mfr table). 
mfrsku (the brand's stock keeping unit, not necessarily unique in your system) 
category (e.g. Brakes) 
subCategory (e.g. Brake Rotors) 
details (e.g. Drilled and Slotteed 'Razr') 
description (Paragraph on part describing it) 
saleprice (?) 
cost (?) 

Применение:

ApplicationID (auto incrementing primary key) 
make (e.g. Subaru) 
model (e.g. Impreza) 
subModel (e.g. WRX STi) 
firstYear. 
lastYear. 

Затем вам нужно присоединиться к таблице (поскольку каждое приложение может иметь ноль или более артикулов, и наоборот, то есть , ваши объекты SKU и Application могут иметь отношения «многие ко многим»). В вашем примере вы знаете, что несколько моделей Subarus часто используют одни и те же части. Эта схема позволяет это.

ApplicationSKU:

ApplicationID 
SKU 

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

1. производители, как Delco и Subaru
2. контактные люди, как Джо и Гарри
3. частей, как левый передний Шарнирный и задний стеклоочиститель Ассамблеи
4. приложения, такие как 1999-2006 Subaru Forester и 1998-2007 Subaru Impreza

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

Создайте таблицы объединений, когда у вас есть отношения «много-ко-многим» между объектами.

Создайте внешние ключи для соединения различных объектов вместе.

Надеюсь, это поможет.

Answer 2

Сменить products.brand на номер products.brand_id и иметь внешний ключ brands.id.

Создать categories таблицу и с полями id, name и parent_id (позволяют NULL), который разместится categories.id своего родителя (NULL означает категорию верхнего уровня). Кроме того, вы можете использовать вложенную модель набора. products будет иметь поле products.category_id (не обязательно subCategory).

Answer 3

Один товар может поместиться более чем на один автомобиль - например, у вас может быть щетка стеклоочистителя, соответствующая Toyota Camry 2010 года, 2009 Scion tC и 2011 Acura TL. Таким образом, вам нужно будет разделить год/модель/модель из таблицы продуктов и составить отдельную таблицу для транспортных средств (id, year, make, model) и перекрестной таблицы (id, product_id, vehicle_id), которая их объединяет.

Answer 4

И помните, когда вы добираетесь до той части, где вы действительно заказываете или кладете вещи в складские запасы, храните фактическую цену во время действия. Цена на продукт - это поиск, он изменяется со временем, но заказы или стоимость элемента в инвентаре должны быть связаны с фактическими затратами на момент ввода записи.