Создание таблицы Metatable в базе данных

Question

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

Таблица: метатаблицы Поля: tableName, tableDescription

Таблица: мета-поля Поля: tableName, fieldName, fieldDesc, fieldDesc

Таблица: метакоды Поля: tableName, fieldName, codeName, codeValue и т. Д. ...

Я никогда раньше не использовал ничего подобного, и мне было интересно, есть ли какие-нибудь "ошибки", на которые стоит обратить внимание.

Является ли что-то вроде этого достаточно приемлемым или вы бы посоветовали против этого?

Answer 1

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

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

Answer 2

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

Создание собственной модели звучит "круто".

Вам, конечно, придется создать собственное управление пространством на метауровне. Это умеренная боль в шее.

Выполнение запросов, оптимизация, обработка индексов и тому, что не является относительно сложным.

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

Кроме того, вам нужно изобрести API. ODBC работает на низком уровне, и вы хотите работать на более высоком уровне, поэтому вам придется придумывать свою собственную «классную» версию ODBC.

«Крутой» фактор лучше всех превзошел всю эту работу. Вы потратите годы, чтобы заставить это работать.

Answer 3

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

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

http://theprogrammersparadox.blogspot.com/2008/06/structuring-noun-verb-data.html

Paul.

Answer 4

Как и предлагал keithwarren7, поработайте с Google, и вы увидите (согласно вашему комментарию), что это совершенно НЕ круто. (Хорошо, это в некоторых случаях, но почти всегда, IMO.)

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

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

Answer 5

Я согласен с комментариями, в которых говорится, что E-A-V выглядит круто, но не круто. Он выполняет большую работу, которая оказывается субмаргинальной или прямо контрпродуктивной.

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

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

Сегодня есть инструменты, которые сделают такое сравнение для вас. Но на самом деле нет ничего сложного, если вы понимаете схему системных таблиц, которые ваша СУБД строит для вас.

Answer 6

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

RDF является логическим расширением дизайна EAV.

Answer 7

Проведите несколько тестов производительности с большим набором данных в одной большой электронной таблице. Если ваш начальник видит низкую производительность, он не будет использовать слово «круто».

Answer 8

Извините, это действительно, как указывают другие авторы, изобретать велосипед.

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

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

Answer 9

Вместо того, чтобы использовать таблицы и поля для выражения динамической структуры, вы всегда можете использовать одно поле данных XML. Многие основные РСУБД разрешают индексировать атрибуты / элементы в XML, поэтому ваши запросы могут быть даже эффективными.