Структура таблицы MYSQL - PullRequest
       21

Структура таблицы MYSQL

3 голосов
/ 08 октября 2009

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

Есть ли у меня 3 таблицы, например:

CREATE TABLE `tbl_products` (
`p_id` INT NOT NULL ,
`p_views` INT NOT NULL ,
INDEX ( `p_id` ) 
) ENGINE = MYISAM 

CREATE TABLE `tbl_categories` (
`c_id` INT NOT NULL ,
`c_views` INT NOT NULL ,
INDEX ( `c_id` ) 
) ENGINE = MYISAM 

CREATE TABLE `tbl_pages` (
`pg_id` INT NOT NULL ,
`pg_views` INT NOT NULL ,
INDEX ( `pg_id` ) 
) ENGINE = MYISAM 

Или у меня есть 1 таблица, где хранятся все, например,

CREATE TABLE `tbl_views` (
`view_id` INT NOT NULL ,
`view_type` VARCHAR( 10 ) NOT NULL ,
`view_views` INT NOT NULL ,
INDEX ( `view_id` ) 
) ENGINE = MYISAM 

Где view_type - это либо товары, категории или страницы.

Какими будут преимущества / недостатки каждого решения?

Заранее спасибо.

Ответы [ 4 ]

2 голосов
/ 08 октября 2009

Мне действительно нравится метод с 1 таблицей, он сохраняет базу данных незагроможденной, что я считаю важным.

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

0 голосов
/ 09 октября 2009

Мое решение о том, какой метод использовать, зависит от количества необходимых записей и вероятности изменения объема информации. Если вы просто перечислили несколько просмотров, одна таблица подойдет.

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

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

Пример. Если продуктам требуется больше информации (например, о стиле, цене или о том, кому разрешено ее просматривать), но страницы и категории никогда не запрашивают, таблица зарезервирует место, которое никогда не будет использовать страницы и категории. Затем записи «Страницы» и «Категория» начинают выглядеть глупо, смешавшись с продуктами.

0 голосов
/ 08 октября 2009

В этом случае я предлагаю перейти с одной таблицы. Единственная разница между тремя таблицами - это тип, поэтому я не думаю, что они необходимы. В качестве дополнительного бонуса к использованию только одной таблицы, если вы добавляете новый тип представления, вам не нужно создавать новую таблицу базы данных - вы можете просто использовать новый ключ view_type. Однако если вам нужны разные фрагменты данных для разных типов представлений (например, представления «страницы» нуждаются в столбце «x», а представления «категории» требуют столбца «Y»), то вам потребуются отдельные таблицы (это называется базой данных). нормализация).

0 голосов
/ 08 октября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...