Можно ли улучшить эту базу данных MySQL или она хороша как есть?

Question

На сайте объявлений у вас есть несколько категорий (автомобили, тс, дома и т. Д.). Для каждой выбранной категории скрытый элемент становится видимым и показывает дополнительные параметры, которые пользователь может указать, если он / она желает.

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

Вот мое простоя сегодня

ТАБЛИЦА КАТЕГОРИЙ:
- автомобили
- mc
- дома

ТАБЛИЦА КЛАССИФИЦИРОВАННАЯ:
- заголовок
- описание
- hide_telephone_nr
- изменяемый
- действие
- цена
- изменить_дату

СТОЛОВЫЙ СТОЛ:
- имя
- passw
- тел
- электронная почта

ЗОНА СТОЛ:
- площадь
- сообщество

СТОЛИЦЫ АВТОМОБИЛЕЙ:
- год
- топливо
- коробка передач
- цвет

MC TABLE:
- год
- введите

ДОМ ТАБЛИЦА:
- Вилла
- Квартира
- Размер
- номера
и т.д.

У меня пока по одной таблице для каждой категории, так что около 30 таблиц. Разве это не слишком много?

Пока что я не создал PK или FK для чего-либо из этого, пока еще не получил ...

Не могли бы вы сказать мне, если эта настройка хороша, или я должен сделать это по-другому?

ТАКЖЕ, как бы вы настроили здесь FK и PK?

Спасибо

Answer 1

Насколько я понимаю, я составлял бы таблицу для всех категорий и сохранял там название и идентификатор категорий. Далее я бы создал отдельную таблицу для хранения дополнительных опций для каждой категории.

MySQL Table 1  
----------------   
Category_ID int PRIMARY KEY  
Category_name varchar  

MySQL Table 2  
---------------- 
Category_ID int   
Entry_Number int PRIMARY KEY (this will keep track of which entry everything belongs to)
Additional_Option varchar  
Additional_Option_Answer varchar (this is the one that stores what your user clicks/inputs)

Например, используя:

POSTER TABLE:
- name
- passw
- tel
- email

Вы должны сохранить category_id, для которого эти данные предназначены, в Category_ID и сохранить name passw tel email в Additional_Option в его собственной строке, а ввод пользователя для этих критериев будет сохранен в Additional_Option_Answer.

Category_ID для Posters будет 1, а для Area будет 2.

Это выглядело бы так, если бы первый пользователь добавил что-то:

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   1                |    name                 |   doug
       1      |   1                |    passw                |   1234

Это выглядело бы так, если бы второй пользователь добавил что-то:

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   2                |    name                 |   Hamlet
       1      |   2                |    passw                |   iliketurtles

Более того, давайте применим другую категорию:

AREA TABLE:
- area
- community

---------------------------------------------------------------------------------------------
    Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
    ---------------------------------------------------------------------------------------------
           2      |   3                |    area                 |   San Francisco
           2      |   3                |    community            |   community_name

Answer 2

Ваш дизайн очень сильно привязан к основным продуктам. Кроме того, вы помещаете то, что кажется взаимоисключающими данными, в разные столбцы (например, дом не может быть одновременно виллой и квартирой?) Я бы выбрал гораздо более обобщенную форму, что-то вроде:

Category 
Classified
Poster

Как в OP, но с добавленными / объявленными первичными ключами.

Затем сгруппируйте все атрибуты, относящиеся к категории, в одну таблицу - например,

Std_Tags {id, category, tag}
{0,Cars,year}
{1,Cars,fuel}
{2,house,type}
{3,house,rooms}

Со значениями в другой таблице:

classified_tags {std_tags_id, classified_id, value}
{0,13356,2005}
{2,109,villa}
{0,153356,diesel}

Это также упрощает построение форм ввода, поскольку шаблон также явно указан, добавляя таблицу типа:

Allowed_values {std_tags_id, value}
{1,diesel}
{1,petrol}
{1,LPG}
{2,Villa}
{2,Apartment}

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

С

Answer 3

Прежде всего вам необходимо создать первичный ключ для каждой таблицы. Обычно лучший способ сделать это - использовать поле последовательного идентификатора с именем id или tablenameId. Это действительно важно. Первичные ключи, привязанные к фактическим данным, могут вызвать проблемы при изменении данных.

category (id PK, name)
category_options (id PK, category_id FK->category.id, option_name)

Так что таблица категорий будет иметь такие значения, как

(1, car)
(2, MC)

и параметры будут иметь значения, такие как

(1, 1, year)
(2, 1, fuel)
(3, 2, type)

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

category_values (id PK, category_options_id FK-> category_options.id, value, classified_id FK->classified.id)

Для классифицированной таблицы требуется поле fk для плаката и идентификатора.

classified (id PK, poster_id FK->poster.id, headline, description, hide_telephone_nr, changeable, action, price, modify_date)

Таблица плакатов довольно хороша, так как она просто добавляет поле id для первичного ключа Я просто думаю, что его обычно называют пользователями.

Под category_options_id FK-> category_options.id Я имею в виду, что category_options_id должен иметь ссылку на внешний ключ для category_options.id.

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

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

Я также должен подчеркнуть, что это не единственно возможное решение, и в зависимости от того, как вы на самом деле хотите использовать данные, это может быть не лучшим вариантом, но оно работает и по крайней мере прилично:)

Answer 4

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

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

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

Category (CategoryId, CategoryName)

Classified (ClassifiedId, PosterId, AreaId, ...)

Poster (PosterId, ...)

Area (AreaId, AreaName, ...)

Property (PropertyId, PropertyName)

CategoryProperty (CategoryId, PropertyId)

ClassifiedProperty (ClassifiedId, PropertyId, Value)