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

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

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

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

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

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

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

12.12.2008 21:21:58
9 ОТВЕТОВ
РЕШЕНИЕ

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

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

9
12.12.2008 22:28:00
Я считаю гораздо круче предоставлять расширяемую схему с помощью средств, предоставляемых вам как частью СУБД. Многие крупные корпоративные приложения, такие как (например, Peoplesoft, SAP level), создают таблицы и при необходимости добавляют столбцы в эти таблицы. Это намного круче.
keithwarren7 12.12.2008 22:12:28
Это не будет так круто для безумного маньяка, который знает, где вы живете, и должен поддерживать вещь в производстве. codinghorror.com/blog/archives/001137.html
Turnkey 13.12.2008 01:08:35

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

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

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

3
12.12.2008 21:47:04

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

0
12.12.2008 21:58:34
я использую это для хранения нестандартных свойств, где я не буду выполнять запросы к ним, поэтому я не полагаюсь на некоторую «магию xml» в RDMBS. (в наши дни это больше JSON, чем XML, но идея та же.)
Javier 12.12.2008 22:02:35

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

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

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

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

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

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

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

5
12.12.2008 21:58:57

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

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

1
12.12.2008 22:27:20

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

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

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

Павел.

3
12.12.2008 22:56:50

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

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

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

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

2
15.12.2008 13:07:23

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

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

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

0
25.01.2009 07:11:53

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

0
25.01.2009 07:53:35