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

Question

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

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

Таблица: MetaFields Поля: TABLENAME, FIELDNAME, fieldDesc, fieldDesc

Таблица: MetaCodes Поля: tableName, fieldName, codeName, codeValue и т. д.

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Построение собственной модели звучит «круто».

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Павла.

Answer 7

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

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

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

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

Answer 8

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

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

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

Answer 9

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