У меня есть несколько таблиц.Дизайн базы данных - что было бы лучше?
Все они имеют следующие поля в них:
item_title | item_description | item_thumbnail | item_keywords
я был бы лучше иметь один items_table с дополнительным полем item_type, а затем объединение с соответствующей таблицей, или просто держать их в отдельных таблицах ?
Я считаю, что хорошо иметь как можно меньше стола. Его легко поддерживать. Трудно представить, что если у вас есть 3000 типов item_type. Тогда будет 3000 таблиц. Таким образом, один стол - хорошая идея для меня в вашем случае. В будущем, когда вы столкнетесь с ситуацией, когда вам нужно отделить таблицу, вы можете легко сделать это.
Таким образом, короткий ответ, ДА.
Если я хорошо понимаю, что вам нужно только нормализовать схему:
пунктов:
item_id
item_name
item_description
items_types
item_id
type_id
типы
type_id
item_file_name
Так Таким образом, вы Калифорния n имеет любое количество позиций с любым количеством типов
Это вы хотите сделать ???
Спасибо Sal00n .. Кажется, что все мои таблицы, например файлы, пользователи, страницы, сообщения - это все списки, которые в основном состоят из следующих cols: item_id | item_name | item_description | item_filename .. Не было бы лучше помещать все эти данные в одну таблицу и иметь дополнительное поле для ввода item_type .. например, файл/сообщение и т. д. – jon
Тогда, возможно, неплохо собрать все данные в одной таблице. – Sal00m
В зависимости от контекста. Если у ваших предметов очень мало различий, а у вас есть , у вас не будет сценария через 6 месяцев, 12 месяцев, 2 года, когда вам нужны предметы, а затем пройдите по маршруту одной общей таблицы «предметы». Если у определенного типа товара есть, у вас есть особые требования, вы можете создать отдельную таблицу, которая содержит эти данные, и создать запрос LEFT JOIN при запросе на включение дополнительных данных.
Я также предлагаю посмотреть другие типы баз данных. Судя по вашему сценарию (много типов элементов с небольшой дисперсией в хранящихся данных), я думаю, что вы можете использовать механизм базы данных на основе документов, такой как MongoDB, а не реляционный механизм базы данных, основанный на данных, например MySQL.
Спасибо @Martin Bean, я действительно шел по строкам каждого типа элементов, нуждался бы в собственной таблице, но все они имели много общих полей, поэтому должны ли эти поля сортироваться в одной большой таблице? – jon
Я бы не смог точно сказать, не зная целей вашего бизнеса, но если бы в вашем коде было бы все ваши разные предметы, чтобы расширить общий класс «Элемент» с теми же полями, то я бы сказал, что это что они должны храниться в одной, отдельной таблице 'items'. –
Спасибо @Martin Bean – jon
По-моему ... Я бы сказал, нет, никогда.
Существует две причины для этого:
Вы действительно хотите сохранить логическое значение в базе данных. Пока для вас довольно очевидно, как это организовано. Но через два месяца (или 1 год) это будет так очевидно? Если кто-то присоединится к проекту, ему нелегко понять, разделены ли разные логические блоки вашего приложения? Я имею в виду ... Это правда, что человек и кошка - животные. Достаточно ли логично хранить оба из них внутри одного окна?
Производительность. Чем короче таблица, тем быстрее будет ваш запрос. Данные будут занимать столько места на вашем диске. И я не говорю о сравнении, чтобы узнать, какой тип элемента вы ищете.Я имею в виду, если вы хотите, чтобы выбрать все страницы вашего приложения, просто сравнить два запроса:
Несколько столов:
Select * from pages_tbl;
одной таблицы:
Select * from item_tbl where type = 'page';
Что будет вы получаете от этого дизайна? Нет производительности, нет места на диске, нет читаемости. Я действительно не вижу в этом веской причины.
Первая причина, по которой вы дали, дает нулевой смысл в контексте. «What ifs» являются недопустимым аргументом.Вторая причина, по которой вы дали, полностью недействительна и не имеет смысла, вам нужно исследовать, как MySQL работает и хранит данные (учитывая тот факт, что вы знаете, какой движок используется). Сказав это, вы дали ответ, который является чисто упрямым и объективно смотрящим на него - это плохой ответ, который является причиной того, что я его уменьшаю. Правильный ответ заключается в том, что более эффективно иметь данные списка в одной таблице, дифференцированные по 1 свойству. –
Спасибо @ N.B. , Я блуждал, если это все еще так, если у каждого item_type была своя таблица для полей, которые не были охвачены в таблице элементов? ... поэтому вам всегда нужно выполнить соединение, чтобы получить все данные элементов. – jon
ОК, поэтому таблицы разделяют поля. Они также разделяют ограничения ?
Например, если таблицы имеют отдельные внешние ключи, вы можете держать их отдельно, или вы можете объединить их в одну таблицу, но держать FKS отдельно:
item_title
item_description
item_thumbnail
item_keywords
table1_id REFERENCES table1 (table1_id)
table2_id REFERENCES table2 (table2_id)
...
CHECK (
(table1_id IS NOT NULL AND table2_id IS NULL ...)
OR (table1_id IS NULL AND table2_id IS NOT NULL ...)
...
)
(Примечание: MySQL Doesn не применяйте ПРОВЕРКУ, поэтому вам нужно будет выполнить эквивалентное принудительное выполнение с помощью кода триггера или клиента или использовать другую СУБД, если сможете.)
Мне нужно будет узнать больше о вашей базе данных, чтобы выяснить что лучше.
с дополнительным полем item_type, а затем присоединение с соответствующей таблицей,
Никогда применять FKs в коде, если вы можете помочь ему. Даже если вы объедините таблицы вместе, не объединяйте FK, а делайте что-то подобное выше. Приведение FK в код в контексте параллельной среды (когда несколько клиентов могут пытаться изменить одни и те же данные одновременно) трудно сделать правильно и с хорошей производительностью - гораздо лучше позволить СУБД сделать это за вас ,
BTW, что такое item_keywords? Это список ключевых слов, разделенных запятыми (или аналогичный), вам нужно будет нормализовать и извлечь ключевые слова в свою отдельную таблицу.
домен (тип данных и проверка), ключ (первичный ключ и УНИКАЛЬНЫЙ) и ссылочное (FOREIGN KEY) ограничение.
Я предлагаю вам использовать одну таблицу для элемента и одной таблицы для типа по следующим причинам (предположим, что существует 10 типов).
В принципе, если у вас есть одна таблица для элемента и одна таблица для типа, вам не придется менять схему и код базы данных для каждого нового вводимого вами типа. Но если вы уверены, что количество типов меньше и не изменится, вы можете использовать таблицы muiltiple.
Это более эффективное время для поиска по одной таблице, чем многие, потому что есть меньше вычислений. Он также менее «тяжелее», поскольку у вас меньше классов сущностей.
В этом случае я бы лично предложил вам просто добавить еще одно поле, чтобы указать тип, чтобы обеспечить легкую фильтрацию строк.
Тем не менее, в целом, это действительно зависит от варианта использования и контекста. т. Е. Предположим, что вы хотите обновить свое программное обеспечение и что вам нужно будет добавить дополнительное поле только в одном из ваших типизированных объектов, в этом случае вы, вероятно, в конечном итоге создадите новую таблицу и перезапишите свой презентация, бизнес и постоянство логики. Просто подумайте заранее (о факторах обслуживания и обновления).
Создайте две отдельные таблицы и присоедините их к вашему требуемому выходу.
т.е.>
1.1'st TABLE (главная таблица ==> item_type)
item_type (item_type_id, item_type_name, статус)
2.2'nd TABLE (подчиненная таблица ==> item_details)
item_details (ITEM_ID, item_type_id, ITEM_TITLE, ITEM_DESCRIPTION, item_thumbnail, item_keywords)
Я чувствую, что стол для подписчиков будет более подходящим. Это позволит избежать большего количества объединений, сложности в программе (код) и ошибок при сравнении нескольких таблиц. Даже будет лучше с точки зрения управления, например, кластеризация db и т. Д.
Если у вас так много таблиц, которые должны иметь одинаковые повторяющиеся столбцы, то да, это хороший способ создать отдельную таблицу для общих полей , Это более эффективно, если эти повторяющиеся столбцы не являются фиксированными и могут быть изменены как добавление еще одного столбца в список стандартных столбцов по умолчанию.
Итак, как вы могли это сделать?
Идея состоит в том, чтобы создать отдельную таблицу и поместить туда общие столбцы по умолчанию. Эта таблица похожа на фиктивную таблицу, то есть столбцы могут быть добавлены/удалены по мере необходимости.
Для ПРИМЕР-
Таблица - DefaultFields
Колонны - item_title | item_description | item_thumbnail | item_keywords
Вы можете также быть в состоянии вставить значения в DefaultFields таблице динамически в цикле, как:
"INSERT INTO DefaultFields (item_table, item_title , item_description,item_thumbnail ,item_keywords) VALUES('"+ field.item_table + "','" + field.item_title + "','" + field.item_description+ "','" + field.item_thumbnail + "','" + field.item_keywords)");
ПРИМЕЧАНИЕ. Поле - это объект, который содержит значения в таблице.
Затем далее вы можете изменить ваши таблицы для создания полей этих значений по умолчанию из таблицы DefaultFields как:
"ALTER TABLE " + item_table+ " ADD COLUMN [" + field.item_title + "] Text"
Это может повторяться для каждой таблицы, чтобы изменить его по мере необходимости.
В этом шаблоне проектирования, даже если вы хотите:
1) добавить еще один столбец или
2) удалить предварительно существующий столбец или
3) изменение предварительно имя существующего столбца
Тогда вы можете сделать это в таблице фиктивных данных, а остальные обновлены командой ALTER table в соответствующих таблицах.
Возможный дубликат [Что более эффективно: несколько таблиц MySQL или одна большая таблица?] (Http://stackoverflow.com/questions/1125004/which-is-more-efficient-multiple-mysql-tables-or- один большой стол) –
Check [link] (http://stackoverflow.com/questions/13810073/mysql-multiple-tables-or-one-big-table) –
Спасибо Nadeem, но эта ссылка пытается получить, если расщепление все столбцы в строки лучше desgin .. Я просто хочу знать, лучше ли таблица с отдельными элементами, а не много спертых таблиц. – jon