Расширенный дизайн базы данных - Какой самый эффективный способ выполнить следующее

Question

Расширенный дизайн базы данных - Какой самый эффективный способ выполнить следующее

0

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

Концепция

Я создаю интерфейс администратора, который позволяет владельцу сайта "создавать" набор контента на основе выбранных контейнеров контента. Интерфейс в настоящее время содержит различные типы данных sql, такие как int, varchar, text и т.д. И позволяет пользователю выбирать тип данных, маркировать его, а затем связывать их вместе в группу.

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

Вопрос

Проблема, с которой я столкнулась, заключается в наиболее эффективном обращении к этим контейнерам. Я не могу просто иметь таблицу с идентификатором экземпляра и идентификатором контейнера, потому что нет способа узнать тип контейнера. Например, таблица content-varchar имеет поле id, а затем поле значения в формате varchar. Таблица content-text имеет поле id, а затем поле значения в формате текста.

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

Каковы ваши идеи/предложения?

sterling 08 янв. 2010, в 03:46

Источник

0

Большое спасибо за ваш отзыв, это был мой первый пост в stackoverflow, и я более чем доволен. Я знал, что слишком усложнил это, и ваши ответы действительно помогли мне, спасибо.
sterling 08 янв. 2010, в 03:14

Теги:

php

mysql

database

database-design

4 ответа

3

Вы делаете вещи на бесполезно низком уровне.

Вы повторно изобретаете реляционную базу данных. Внутри реляционной базы данных.

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

Один из вариантов заключается в использовании структур более высокого уровня (не отдельных строк, а составных записей с несколькими связанными друг с другом элементами).

Другой выбор - использовать только текст. Это проще. В конце концов, все это становится текстом, когда HTML отправляется обратно в браузер.

"... различные типы данных sql, такие как int, varchar, text и т.д., и позволяет пользователю выбирать тип данных, маркировать его, а затем связывать их вместе в группу.

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

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

или

Обозначьте простые отдельные текстовые поля с меткой поля и меткой группы. Гораздо проще. Просто текст с двумя клавишами. Вы можете получить "группу" и использовать пары label/value для заполнения шаблона. В Django это одна строка кода для извлечения строк, превращения их в словарь и передачи его в шаблон.

S.Lott 07 янв. 2010, в 23:58

0

Я ценю ваши отзывы, и у меня было ощущение, что я уже слишком усложняю это, как обычно. Хотя, я не совсем понимаю ваш ответ, я думаю, что вы говорите, что сказал амфетамина?
sterling 08 янв. 2010, в 03:02
0

Спасибо за это дополнительное понимание. То, что вы описываете, похоже на то, что я делаю. Ответ Джона Феминеллы в значительной степени объясняет мой процесс, но я его немного расширяю. Еще раз спасибо за этот бесценный отзыв. Я склонен увлекаться и усложнять вещи.
sterling 08 янв. 2010, в 20:25

1

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

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

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

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

Решение не было быстрым, но оно было очень гибким, надежным и простым в использовании.

KenFar 08 янв. 2010, в 12:32

0

Спасибо за вклад здесь, я думаю, я могу найти здоровый баланс скорости и гибкости с правильным дизайном стола. Для любых двоичных объектов (изображений / звуковых файлов) я просто сохраню их в файловую систему и сохраню путь.
sterling 08 янв. 2010, в 20:08

1

Здесь, что руководство MySQL должно сказать о TEXT и BLOB-полях:

В большинстве случаев столбцы BLOB можно рассматривать как столбцы VARBINARY, которые могут быть как можно большими. Аналогично, столбец TEXT можно рассматривать как столбец VARCHAR.

Перевод: использование всех столбцов TEXT или BLOB не будет пустым. MySQL усекает то, что он не использует (например, в VARCHAR).

amphetamachine 08 янв. 2010, в 00:43

0

Это имеет смысл, и сделает вещи намного проще. Я не предвижу необходимости рассказывать что-либо в двоичном формате, так как я могу просто сохранить имя файла изображения вместо целого изображения, так что мне, возможно, удастся обойтись без использования только текста. Затем я могу определить модели, которые будут правильно обрабатывать такие вещи, как даты и метки времени. Спасибо за ваш вклад здесь!
sterling 08 янв. 2010, в 03:04

Ещё вопросы

Большое спасибо за ваш отзыв, это был мой первый пост в stackoverflow, и я более чем доволен. Я знал, что слишком усложнил это, и ваши ответы действительно помогли мне, спасибо.
Я ценю ваши отзывы, и у меня было ощущение, что я уже слишком усложняю это, как обычно. Хотя, я не совсем понимаю ваш ответ, я думаю, что вы говорите, что сказал амфетамина?
Спасибо за это дополнительное понимание. То, что вы описываете, похоже на то, что я делаю. Ответ Джона Феминеллы в значительной степени объясняет мой процесс, но я его немного расширяю. Еще раз спасибо за этот бесценный отзыв. Я склонен увлекаться и усложнять вещи.
Спасибо за вклад здесь, я думаю, я могу найти здоровый баланс скорости и гибкости с правильным дизайном стола. Для любых двоичных объектов (изображений / звуковых файлов) я просто сохраню их в файловую систему и сохраню путь.
Это имеет смысл, и сделает вещи намного проще. Я не предвижу необходимости рассказывать что-либо в двоичном формате, так как я могу просто сохранить имя файла изображения вместо целого изображения, так что мне, возможно, удастся обойтись без использования только текста. Затем я могу определить модели, которые будут правильно обрабатывать такие вещи, как даты и метки времени. Спасибо за ваш вклад здесь!

John Feminella · Accepted Answer · 2010-01-08T01-18-00.000Z

Если мне что-то не хватает, это звучит ужасно сложно. Но похоже, что вы размещаете реляционную базу данных в реляционной базе данных. Это обычно неправильный путь, чтобы идти о вещах.

Тем не менее, если вы настаиваете, здесь есть несколько замечаний:

ContentSet определяет один или несколько ContentItems.
ContentItem может быть одним из нескольких четко определенных примитивных типов ContentTypes.

Итак, похоже, что у вас будет четыре таблицы:

content_sets: ContentSets и связанные с ними метаданные, такие как пользователь, который создал каждый, заголовок наборов и т.д.
content_items: ContentItems, а также внешний ключ к ContentSet, к которому они принадлежат.
content_types: список возможных типов, которые могут быть сохранены в каждом ContentItem. Ваше приложение будет обеспечивать правильность данных, хранящихся в каждом элементе.
content_groups: экземпляры ContentSets, содержащие реализованные данные и внешний ключ для ContentSet, являются экземпляром. Используйте свойство bag/blob/текстовое поле для хранения самих данных.

Да, вы утверждаете, что именно правильный подход, который я реализовал, мне не хватало того, что я мог хранить каждый тип данных в одном и том же контейнере, если бы использовал столбцы TEXT, как указано amphetamachine. Большое вам спасибо за ваш вклад здесь.
«Вы помещаете реляционную базу данных в реляционную базу данных». Я думаю, что делать это - интересное, хотя и чрезвычайно сложное упражнение. Само масштабирующаяся база данных - интересная концепция для меня.