Понимание больших связей данных mysql

Question

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

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

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

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

Answer 1

Просто чтобы дать пример:

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

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

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

Answer 2

Sketch взаимодействия

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

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

Продолжаемости и повторного

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

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

ОРМ, чтобы спасти

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

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

• Good Resources for Relational Database Design
• Good PHP ORM Library?
• How should a programmer learn great database design?

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

Answer 3

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

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

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

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

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

Если у вас normalize rigorously, у вас будет база данных, где каждый тип сущности имеет свою собственную таблицу в базе данных. Однако денормализация по-разному (например, объединение двух типов сущностей в одну таблицу) может иметь преимущества, которые могут (в зависимости от размера и формы ваших данных) избавлять от затрат. Сначала я бы посоветовал стратегию keeping all content types separate, и рассмотрим их объединение как tactical denormalization, если это окажется необходимым.

Answer 4

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