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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Павел.

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

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

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

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

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

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

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

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