Понимание больших отношений данных MySQL

Question

Я пытаюсь научить себя, как использовать SQL, а именно mysql.

Что я пытаюсь понять, так это то, как обращаться со многими различными типами данных в одной таблице. Допустим, я создаю веб-приложение, и у меня есть много разных типов контента (элемент блога, элемент комментария, файлы, страницы, формы), которые мне нужны для хранения различных полей данных для каждого. Буду ли я создавать новую таблицу для каждого отдельного типа контента, поскольку каждый тип контента имеет свои собственные уникальные требования к полям, или есть лучший способ сделать это? Кажется, немного больше, чтобы создать новую таблицу для контента каждого типа. Если бы в моем веб-приложении было 30 типов контента, это было бы 30 таблиц только для типов, что, кажется, немного. И если бы у меня был новый тип контента, мне пришлось бы создать новую таблицу, которая содержала бы все обязательные поля, необходимые для этого типа.

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

Немного смущен тем, что делать.

Answer 1

Вам нужно прочитать книгу о создании сайтов с PHP и MySQL. Это хорошее отношение к Google в первую очередь, потому что некоторые программисты считают это ленивым вопросом. Я предлагаю прочитать "Изучение PHP MySQL и JavaScript". В любом случае, прежде чем вы начнете кодировать свой сайт, вам нужно спланировать, какую информацию вы будете хранить, а затем создать свою базу данных. Скажем, в регистрационной форме будут указаны имя, имя, отчество, дата рождения, страна, пол и адрес электронной почты. Вы создаете таблицу с именем скажем «USER_INFO» и назначаете тип данных, соответствующий данным, которые вы хотели бы сохранить, число, текст, дату и т. Д., Затем через PHP вы подключаетесь к MySQL и сохраняете или извлекаете нужные данные. , Вам действительно нужно прочитать книгу или учебник, чтобы получить полный ответ, И GOOGLE: P

Answer 2

Взаимодействие эскиза

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

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

Расширяемость и повторное использование

Например, вы хотите иметь User, который может публиковать BlogPost с. Каждый BlogPost может иметь набор Tag с и соответствующий набор Comment с. Attachment s могут быть добавлены в BlogPost, а также в комментарий.

Повторное использование и расширяемость является ключом. При наброске ваших взаимодействий старайтесь изолировать зависимости. Думайте об этом в ОО манере. Давайте рассмотрим Attachment еще немного. Вы можете создать таблицу вложений, а затем расширить ее, создав BlogPostAttachment и CommentAttachment, где вы можете легко создавать отношения между этими надежными объектами. Это создает легко расширяемый тип контента, который вы можете использовать повторно, например. UserDetailsAttachment

ORM для спасения

Изучив пример использования кода Object relational mappers, например Doctrine или Propel , вы можете понять некоторые идеи по расширению таблицы. Практические примеры всегда лучшие.

Смежные вопросы SO, которые могут вас заинтересовать

• Хорошие ресурсы для проектирования реляционных баз данных
• Хорошая библиотека PHP ORM?
• Как программист должен научиться великолепно проектировать базы данных?

Я знаю, что это долгий путь, но, учитывая факторы создания крупномасштабных приложений БД с множеством отношений и типов сущностей, лучше всего использовать помощь ORM в долгосрочной перспективе

Answer 3

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

1. Простота : Каждая таблица может быть довольно простой, а ограничения просты. Например, если у ContentType1 есть поле, связанное с другой таблицей, вы можете сделать этот внешний ключ в структуре базы данных, а СУБД позаботится о целостности данных за вас.
2. Эффективность индексирования : если ContentType2 необходимо индексировать по дате, но ContentType3 нужно индексировать по имени (для простейшего примера), наличие их в двух отдельных таблицах означает, что каждый индекс существует именно для данные ему нужны и больше ничего. Объединение их в одну таблицу означает, что вам нужны оба индекса, охватывающие объединенный набор данных, который является более сложным и занимает больше дискового пространства.

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

С другой стороны, если у вас есть два очень похожих типа контента (например, как в случае с StackOverflow, приведенным выше), вы можете получить некоторые преимущества, объединив их в одну таблицу:

1. Простота : Вам нужно всего лишь один раз закодировать таблицу - если все сделано правильно (то есть два типа контента действительно очень похожи), это может сделать вашу кодовую базу меньше и проще.
2. Расширяемость : если появляется третий тип контента, который снова похож на первые два и аналогичен так же, как первые два, соответствуют друг другу, таблицу можно просто расширить, чтобы сохранить все три типа контента.
3. Индексирование по производительности . Если наиболее распространенным способом получения данных является объединение двух типов контента и упорядочение их по дате (скажем), поле, которое является общим для обоих типов контента, то может быть неэффективно иметь две отдельные таблицы, которые должны многократно повторяться. UNIONed, а затем отсортированы. Объединение двух типов контента в одной таблице позволяет вам поместить один индекс в поле даты, что позволяет быстрее выполнять запросы (хотя помните, что вы можете получить аналогичную выгоду от индексированных представлений).

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

Answer 4

Просто для примера:

Переполнение стека само использует ту же таблицу базы данных (называемые постами) для вопросов и ответов. Хотя эти два типа данных не идентичны, создатели сайта посчитали их достаточно схожими, чтобы поместить их в одну таблицу. Есть поле PostTypeId, в котором указано, является ли это сообщение вопросом или ответом. В ответах поле «Заголовок» будет иметь значение NULL, в вопросах другие столбцы могут игнорироваться.

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

Я знаю, что на самом деле это не ответ, и другие разработчики, возможно, даже решили поместить вопросы и ответы в разные таблицы; но это дает некоторую перспективу. Короче говоря: это зависит:)