Универсальное представление данных

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

Первая таблица (метаданных) описывает поля таблицы данных, скажем, сотрудников (пусть это будет таблица № 10), например, в виде:

№ кол-ки Имя кол-ки Полное наим. Тип значения Длина в байтах Точность1 ПорНо Порядковый номер / индекс N 5 02 ТабНом Табельный номер N 5 03 ФамИО Фамилия И.О. C 21 04 Фамилия Фамилия сотрудника C 16 05 Имя Имя сотрудника C 12 06 Отчество Отчество сотрудника C 16 07 УкрФам Украинская фамилия C 16 08 УкрИмя Украинское имя C 12 09 УкрОтч Украинское отчество C 16 010 ИдКод Идентификационный код C 16 011 ДатаРожд Дата рождения D 8 012 ОснДатаПриема Основная дата приема D 8 013 ОснДатаУволн Основная дата увольнения D 8 014 ОснФирма Основное предприятие работы R 0 014 ОснПодр Основное подразделение работы R 0 015 ОснУчасток Основной участок работы R 0 016 ОснЧасТариф Основной часовой тариф N 9 517 ОснДнТариф Основной дневной тариф N 10 418 ОснМесОклад Основной месячный оклад N 12 2. . . . . . . . . . . . . . . . . .

(здесь N - число; C - строка; D - дата; R – ссылка, в виде номер (индекс) таблицы / номер (индекс) строки или ряда).

Вторая таблица (данных) содержит собственно данные, причем в их временном измерении. Т.е. любое поле таблицы, кроме первого, которое является ключевым индексом, может менять свое значение во времени. Если дата модификации данных не пуста, то данное поле конкретного ряда имеет новое значение с указанной даты. Поменялась дата модификации, поменялось значение. Поле вида: (Ряд, Колонка), может иметь или не иметь ссылку на строку другой таблицы, причем, в любом случае, оно представлено своим универсальным значением . Если ссылки нет, то универсальное значение это просто строковое представление числа, даты или самой строки. А если ссылка существует, то универсальное значение означает просто строковое представление (порядка 20 байтов) данного ссылочного объекта для целей сортировки .

Поскольку обе таблицы (данных и метаданных) имеют фиксированные колонки, то все они индексируются. Тем самым мы имеем универсальную индексацию всех полей базы данных.

Пример таблицы данных для справочника сотрудников (скажем, таблицы № 10) представлен ниже. Полагаем также, что таблица № 5 это таблица подразделений всех учитываемых в базе данных предприятий. Номера подразделений мы не описываем.

№ Ряда № Кол-ки Год модиф. Мес. модиф. День модиф. № ТаблСсылки № РядаСсылки Универс. значение. . . . . . . . . . . . . . . . . . . . . . . .1 14 5 1 ПродажОтдел1 14 2009 1 1 5 2 СнабженияОтдел1 14 2010 1 1 5 3 ВалютныхОперацийОтд1 14 2011 1 1 5 4 ТаможенныйОтдел. . . . . . . . . . . . . . . . . . . . . . . .1 18 10001 18 2009 1 1 20001 18 2010 1 1 30001 18 2011 1 1 4000. . . . . . . . . . . . . . . . . . . . . . . .

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

Таким образом, может быть описана любая таблица и даже вся база данных одним контейнером. Однако для Win32 не целесообразно объединять таблицы, так как есть ограничение на длину одного файла (2 – 4 гигабайта).

Поскольку мы имеем фиксированную структуру базы данных, полностью проиндексированную, то можно пользоваться дешевыми движками база данных, например Visual FoxPro или даже самописный движок, как у 1С77. При оптимальной организации данных, вполне можно получать приемлемые результаты для предприятий среднего уровня. Впрочем, ничего не мешает использовать промышленные сервера баз данных, например, MS SQL Server.

iscrafmEmery, а что делает таблица №6, как она выглядит?
Прикалываетесь? Ее здесь нет, хотя она будет иметь похожую структуру.

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

Посмотрел только что WIKI, довольно мудреное определение, у меня вроде проще. Вот еще накручено:
http://www.askdev.ru/question/3120/Использовать-ли-EAV-модель-данных/ .

iscrafmEmeryПонимаю, что новое это хорошо забытое старое. Но многие из нас выросли из 1С-овских штанишек и ее организация данных уже всех достала.

т.е. это идея для 1С-ников? От изменения названия суть не меняется. Потому что остальные просто используют нормальную организацию данных изначально.
Идея независима от 1С, хотя может быть применена и там, если писать конфигурации самому с нуля. Я не знаю, возможно ли отвязать представление данных в 1С-овском CListCtrl от соответствующих dbf-таблиц? Если бы я мог сам наполнять содержимое этих визуальных списков (да еще в виртуальном режиме), то в 1С77 можно было бы вдохнуть «вторую жизнь» :) . Тем не менее, организацию периодических реквизитов справочников 1С лучше делать по этой схеме. Тогда для каждого 1С-овского справочника должна будет создана таблица модификации всех реквизитов, кроме ключевого кода, которая может быть пустой, если поля основных таблиц не меняются во времени.

Что касается «нормальной организации данных», то если писать независимого клиента под некоторую базу данных, то уже ничем не ограничен. Однако данная структура, которая очень похожа на EAV, хотя EAV не предлагает отслеживание полей данных во времени, лично мне кажется вполне привлекательной, чтобы поэкспериментировать с ней.

Last1Cmenвчера это поле было "видом овоща" сегодня уже "номером ТТН" а позавчера вообще "окладом"... а послезавтра наверное прийдется "курс валюты" там вести

просто замечательно и удобно потом будет генерить отчеты по такой структуре
Любое поле произвольной таблицы характеризуется своими координатами и временем модификации (если пусто, то без ограничений во времени), а также ссылкой на произвольную строку некоторой таблицы (если необходимо) и (всегда) своим 20-ти байтным универсальным (строковым) значением, используемым для сортировки. Скажем в 1С77 нельзя сортировать ссылочные объекты, так как фактически они сортируются по своему внутреннему идентификатору (36-тиричному значению), что бесполезно для практики. А у нас можно, ибо ссылка имеет еще свое 20-ти битное строковое представление.

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

iscrafmдля начала ТС нужно попытаться ответить на простой вопрос: а зачем это все и что мешает сделать нормальную структуру данных?
Есть шанс упростить и стандартизировать учет на предприятии, причем на «легких» движках БД. Всех делов то, написать собственного клиента.

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

СУБД-то разделяют, более того многие сервера БД и клиентов могут не иметь. Задача состоит в написании собственного клиента подключаемого к некой внешней БД, организованной по предлагаемому варианту.

vadiminfoВы, скорее, замахнулись на преодоление структурных ограничений РМД.
Действительно, она относится к структурированным, а Вы типа делаете некий каракас, куда моно запихнуть типа произвольные струтуры реального мира. Т.е. у Вас типа полуструктурированная МД.
На базе реляционных форматов это обычно EAV, а в более или менее по взрослому это XML, т.е. не реляционное представление, система запросров.
Какие замашки? :) Идея очень простая и легко реализуется. Возможно только некоторые нюансы возникнут при организации реальных запросов. Но ничто не помешает искать нужные решения по мере поступления проблем :) .

EAV разжевывается очень нудно. Кто не в теме не поймет. Хотя эта идея очень простая, вместо хранения редких таблиц (даже многомерных) использовать хранение только их непустых элементов в таблицах фиксированной структуры. XML хорош как переносимый формат (экспорт / импорт / пересылка по сети), но в постоянной работе его использовать невыгодно.

Начинать экспериментировать я собираюсь на самопальном «движке» типа «1C Database Engine for .DBF, .CDX» (файл dbeng32.dll, размером всего 143 Кб), затем VFP Runtime, а потом уже можно будет пробовать платные и бесплатные sql сервера.

vadiminfoСмотртите, как проектировщик, Вы должны следовать неким типа критериям: простота, структурное соотвествие предметной области структурнам БД. Это Вы утрачиваете: у Вас структура это всего две таблы, не соотвествущеие реальному миру: одна описание данных, вторая типа аудита что-то. А выковырять структуры сущностей реального мира из них есче нуно. Причем с промощью реляционной системе запросов, поскоку сруктура рел формата. А ить простота извлечение инфы важнейшая цель сроздания БД. А бывают сложные запросы и для нормальной БД, а Вашей это все тока много усложнится. Навязывать ОЦ тоже стремней. Ить Вы остались в рамках реляционных средств.
Потому, раз Вы чувствуете в себе призвание, то, возможно, стоит сосредолточиться на решениях в корне отличных от РМД.
Опыт внедрения реальных конфигураций (100% собственных) на предприятиях у меня есть. Поэтому я не вижу никаких принципиальных трудностей (хотя это и не означает, что они не появятся в дальнейшем :) ) в реализации данной модели (адаптированной EAV). Ведь все поля предлагаемых таблиц будут проиндексированы. А любой SQL держится, по сути, на индексах. Только у нас, в силу фиксированности структуры БД все должно быть существенно проще.

iscrafmEmeryЕсть шанс упростить и стандартизировать учет на предприятии, причем на «легких» движках БД. Всех делов то, написать собственного клиента.
к некоторой схеме данных вы добавляете, дополнительно, еще одну. И для нее предлагаете специализированного клиента, который будет это интерпретировать. В чем упрощение?
Как раз клиент должен быть универсальным. Существует множество универсальных серверов БД, но я не знаю, подходящих для меня, универсального клиента БД. Как вариант, я вижу подобного клиента написанного на MFC или Qt, так чтобы я мог легко конфигурировать пользовательский интерфейс (лучше, чем в 1С77) и самостоятельно обрабатывать сообщения вроде LVN_GETDISPINFO, LVN_ODCACHEHINT, LVN_ODFINDITEM и т.п., как для контрола SysListView32 . А уж функцию доставки данных можно уже реализовать вне клиента, на стороне сервера БД. Как идея, можно попробовать перехватывать данные уведомления в самой 1С77 и реализовывать отображение данных в списках только динамически . Тогда и «семерка» будет достойным кандидатом для экспериментов :) .

Last1CmenEmeryЧто касается отчетов, то не вижу никаких проблем. В своей собственной конфигурации 1С я написал собственный генератор отчетов уровня пользователя. Для этого широко использую предварительную обработку данных. Кстати, это весьма мощная идея, наряду с предварительной подготовкой (проводкой, расчетом) данных.

очень легко и просто вместо select sp358 from ra123 будет писать

select case when сm.sp36 between @NPeriod_1 and @KPeriod_1 then sp358 else sp89 end from ra123 (это если две модификации)

я просто предвкушаю себе удобство разработки и главное "сопровождения" в такой среде :)

в принципе как шаблон-конструктор для разработки некой начальной базы под конкретное решение идея имеет смысл быть но "только толкнули" сразу надо от неё уходить в область более-менее фиксированных структур с таблицами "по назначению"
Не понимаю, о чем Вы? Например, мой движок расчета заработной платы (из первичных табелей 1С77 во вторичные) реализован на VFP, который «общается» с «семеркой» как с DDE сервером. Чтобы избежать использования «неудобных имен» я автоматически сгенерировал VFP модуль типа:


и пользуюсь себе удобными именами без проблем :) .

alneoИерархические БД?
Пример для учета на предприятии можете привести?

LSVЕдинственная проблема, ИМХО - производительность будет посредственной.
Производительность это, прежде всего, вопрос организации самих данных и доступа к ним. А идеи тут могут быть разные. Например, очень помогает предварительная обработка данных, «правильная» индексация и ее использование, собственно структура БД и т.д. Эта тема «вечная» :) .

guest_20040621Просто потрясающе, насколько одинце сносит башню. :( На мой взгляд, Emery, изначально кривые идеи нет смысла тиражировать.
Троллинг?

vadiminfoEmery,
Я лишь хотел, чтобы Вы более критично относились к простеньким идеям.
Лучший критерий истины - практика :) .