Имеется задача написать картографическую программу, которая бы могла привязывать к объектам на карте различную информацию. Т.е. класическая задча - имеем разные классы объектов, колчиество классов заранее неизвестно.
надо написать прогарамму, чтобы можно было добавлять новые классы без изменения кода программы. Можно хранить данные в структуре типа EAV. А можно хранить в виде плоских таблиц, а вот уже в метажнных описать как эти плоские таблицы обрабатывать. Мне кажется, что этот подход будет лучше EAV.
Делал ли кто-нибудь что-то подобное?

Объекты на карте это действительно СОВСЕМ разные объекты. Например, это может быть скважина или река. Скважина обладает глубиной, азумутом, датой начала и окончания бурения. К скважине могут быть прицеплены дочерние объекты, например, химсостав проб на разной глубине. Река имеет ширину, глубину, исток итд..
Речь идет не о графических объектах, а о дополнительной информации связанной с ними. Данные в большей совей части буду не набиваться, а импортироваться из уже существующих БД поэтому табличное представлеие более естественное. Какой выигрыш дает EAV по сравнению с ROT я признаюсь не сильно понимаю.

Обработка конечно будет.. Будет и ввод и поиск, и отчеты итд.. Также будет, например, объединение данных из разных источников.
Также будет отношение многое ко многому между объектами геометрическими и информационными.

ModelRПривязка к карте - это отдельный вопрос, не нужно связывать его со свойствами привязываемых объектов
да, конечно так и есть.. Т.е. на самом деоле имеется просто большое количество классов и экземляров класса.
Я просто думаю, что те преимущества которые дает EAV (гибкость) обеспечат и отдельные таблицы. Ну придется в код поддержки метаданных добавить создание и модификацию таблиц. Зато будем иметь следующие плюсы
Часть информации из метаданных будет браться из описания таблиц. Например, тип данных, длинна varchar итд

Ссылочная целостность

Скорость исполнения

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

не будет проблемы с хранением различных типов данных в одной колонке или нескольких таблицах.

Возможность писать БЫСТРЫЕ традиционные запросы.

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

Petro123
разговор был о:
- атрибуты - таблиц А атрибутов (EAV)

Это я понял.. :) Не понял чем это лучше кроме кол-ва таблиц.

ModelRНе все. В EAV просто выдать все объекты, которые обладают заданным значение все равно какого свойства.
Это врядли потребуется
ModelRНапример, все, что-хоть как-то связано с данной скважиной. Нужно ли это в Вашей задаче - отдельный вопрос.
Связи это отдельный вопрос... Думаю, будет достаочно просто это сделать в бизнес уровне

Petro123
т.е. Вы предлагаете на каждый атрибут скважины - отдельную таблицу?
Вы хоть решение своё приведите.
Я предлагаю на каждый класс обектов свою таблицу. Т.е. на все скважины одна таблица, на все реки другая таблица итд. ПЛЮС метаданные похожие на те, которые используются в EAV.

Petro123
смотри не ошибись в модели. Дорого будет стоить.
- сложно сказать сколько у тебя разных типов.

Это я и сам не знаю. И главное, они будут добавляться в просессе эксплуатации
Petro123
- перечитай ModelR он дело говорит

Про EAV я уже достаточно почитал.
Petro123
- есть ГИС системы и критерии там другие (быстрая выборка по ModelR или координатам)

У меня не совсем GIS, это скорее довесок. Т.е. сами графические объекты с координатами сидят в своих таблицах и я их не трогаю. Будет связь моих объектов с гисовскими через отдельную таблицу с двумя FK. Один на гисовскую таблицу, другой составной псевдо-ключ "Имя таблицы"+ID. Вот тут кстати, "некрасивое" место.
Petro123
- разве проще у тебя будет запрос (найти/нарисовать все объекты попавшие в экран (т.е. x_min, .......))

Такими запросами будет заниматься другое приложение.
Petro123
- в ГИС большинство делается классами на клиентах, который в БД "сидят" в БЛОБ.
Это я знаю.. Имел удольствие писать парсинг этих блобов для Geomedia

Petro123
PS. Если у тебя это только часть системы, то вообще сложно говорить о чём то.
У меня основная задача БД - выдать по географическим координатам, а у тебя это всё где-то отдельно
Просто еще нет даже определенности с каим из ГИС то будет работать. Георграфическая привязка это важно, но главное. Например есть еще привязка к административному делению итд. Да и информация может быть связанна, например, с несколькими географическими объектами. Или наоборот.. К одному географическому объекту могут быть привязаны несколько информационных объектов.

Petro123
но перечень ВЕРОЯТНЫХ запросов то должен быть.
Если их нет, то ВСЁ (все классы клиента) запихать в БЛОБ и делов то.
А вот этого нет :(
Пока просто показ связанных объектов. Если дела пойдут хорошо то будет развитие а вот куда?? Непонятно.

Petro123Приведи структуру.
Диаграмму сейчас нарисовать не могу
1) Связи в таблицах через FK. Например, есть месторождение, есть скважина. Скважина ссылается на метсорождение. В идеале в метаданных такие связи должны быть описаны. Хотя бы привести название связи ("Принадоежит", "Содержит", "Находится на" итд)
2) Возможно потребуется прикрутить связи в стиле EAV. Т.е. табличка с полями
LINK_ID
LINK_TYPE_ID
LINK_FROM_TABLE
LINK_FROM_ID
LINK_TO_TABLE
LINK_TO_ID

Petro123Один ко многим?

Да. А можно и многое ко многому прикрутить. Через промежуточную таблицу.
Например связь между месторождениями и листами карт или отчетами на которых они отображены.

Под отчетами и картами подразумеваются бумажные документы. Например, "Карта полезных ископаемых Сибири" или "Отчет метосоматического отряда за полевой период 2006 года"

Petro123
с картами и отчётами сомневаюсь - это динамика и перевычисляется при изменении размера листов, например.
Ну надо еще расмотреть такую вещь как номенклатурные "листы". С одной стороны географические координаты однозначно определяют соответсвие объекта нескольким номенклатурным листам. С другой стороны, листы также имеют автора, дату топоосновы итд.

Тут вообще хитрая ситуация. Данные начинают набиваться уже сейчас, а программа начнет писаться не раньше чем через год. Финансирования сейчас нет

Petro123
ГОС-структура наверно. Только они деньги не считают, т.к. государственные ;).
Причем тут деньги? Как раз хочется деньги сберечь, чтобы не делать работу дважды.

Отрисовка для меня не важна, этим занимается сам GIS