Концептуальный вопрос по архитектуре БД "Каталог"

← →
Empleado © (2007-02-15 12:32) [0]

Хотелось бы услышать ваши мнения по поводу следующего.
Спасибо заранее.
*************************************************

Дано:
Несколько каталогов, от разных поставщиков, обновляемых эпизодически (изменения цен, номенклатура и т.д.).
Каждый поставщик придерживается своих стандартов представления и форматов данных.
Размеры каталогов - от 1.000 итемов до 150.000. Количество каталогов - теоретически любое, практически - скажем, около 20 разных.
DB: SQL2005.

Необходимо:
Организовать один общий каталог (из множества разных), содержащий в одном месте всю необходимую информацию для работы с итемами из разных каталогов, с возможностью ссылаться только на одну таблицу из разных мест DB бизнес-приложения.

(Пример: Клиен заказывает 15 автопокрышек, 6 шил и 32 рубанка. Для всех итемов - разные поставщики; разное время зачисления товара на склад и т.д.)

Мои мысли и возможные решения:
(Опустим момент перегона данных из формата поставщика в SQL;
опустим также представление данных для пользователя)
Закусив губу и почесав мозгами затылок, рассматриваю пока два варианта.
Оба варианта представлены вот тут:
http://empleado.hotbox.ru/DBSchemas.jpg (160 kb)

I. (см. Schema 1)
Принцип заключается в объединении всех итемов разных каталогов в одной таблице с данными, более-менее общими для всех разных каталогов (например: название, вес, размеры) - см. таблицу CatalogItems1.
Все специфичные характеристики (например, %-ное содержание золота в часах, уровень радиоактивности молока, диаметр боеголовки) описаны в других таблицах - см. ItemFeatures1 и CatItemFeatures1.
Отношение CatVersionItems1 описано отдельной таблицей, чтобы не переписывать заново одни и теже итемы для новых версий каталогов.
Для сохранения универсальности, введена таблица DataTypes1, описывающая тип данных особых характеристик (галлоны, баррели, удавы и т.д.). Естественно, превращение типов должно быть реализовано программистом в приложении.

Была еще такая идея, в дополнение к вышенаписанному: добавить точную копию таблицы CatalogItems1, например UsedCatalogItems1, в которой будут содержаться только "используемые" итемы, для облегчения таблицы, на которую будут ссылаться все коммерческие предложения, контракты, гарантии, склады и т.д. Не знаю, насколько это рационально.

Мои большие сомнения по поводу I:
Размеры таблицы CatalogItems1, а особенно CatVersionItems1 (несмотря на то, что там только 2x integer).
И, соответственно, скорость производимых операций по выборке и join"ам.
Сразу отвечу - все данные сразу вытаскиваться не будут :). Предполагается организовать постраничную выборку и целенаправленный поиск.

II. (см. Schema 1)
Идея следующая. Каждый каталог рассматривается отдельно.
Поступил новый каталог, например Catalog_Supplier3 - пишем к нему новый модуль работы с ним (визуализация) и экспортные функции данных в другие таблицы.
Таблица UsedCatalogItems2 имеет все поля данных каждого каталога, т.е. новый каталог - смотрим, какие поля добавить в UsedCatalogItems2 и в соответствующую таблицу отношений полей к каталогам.
Как только использовался один из итемов каталога (например в заказе на покупку), помещаем его, если его там еще нет, в таблицу UsedCatalogItems2, и дальше используем ссылки из других таблиц (заказы, поступления и т.д.) на эту.

Мои сомнения по поводу II:
Не сложно ли будет строить запросы по данным одного заданного каталога из UsedCatalogItems2, учитывая, что нужные поля надо тоже искать в другой таблице CatFields2?

III. ... (Ваш вариант) ?...

Вопросы:
Какой вариант вам кажется наиболее приемлемым? Почему (если можно - обоснуйте)?

Спасибо за любые предложения, замечания, мысли.

← →
Sergey13 © (2007-02-15 13:29) [1]

Сильно много букв. Всего не осилил. Но бросилось в глаза

> (Опустим момент перегона данных из формата поставщика в SQL;
Это самое интересное. ИМХО. 8-)

> Все специфичные характеристики (например, %-ное содержание
> золота в часах, уровень радиоактивности молока, диаметр
> боеголовки) описаны в других таблицах - см. ItemFeatures1
> и CatItemFeatures1.

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

← →
Empleado © (2007-02-15 13:38) [2]

>Сильно много букв. Всего не осилил
Буквов много, согласен.
В принципе, можно читать только до ссылки;
по ссылке http://empleado.hotbox.ru/DBSchemas.jpg - небольшие схемки, по ним понятен принцип;

остальное - мои рассуждения, пояснения, мат и тд

> Sergey13 © (15.02.07 13:29) [1]

Это самое простое, на мой взгляд :)

ПС. сорри, не закрыл черный тэг в первом мессаже.

← →
stone © (2007-02-15 13:41) [3]

> (Пример: Клиен заказывает 15 автопокрышек, 6 шил и 32 рубанка.
> Для всех итемов - разные поставщики; разное время зачисления
> товара на склад и т.д.)

Тут тебе понадобится уникальная идентификация товара. Все остальное это уже таблицы-расширения.

← →
Sergey13 © (2007-02-15 13:51) [4]

> Это самое простое, на мой взгляд :)

Ну не знаю. Кому как видимо. Конвертация 1 источника может и вправду не так сложна, а вот многих (и наверное не всегда постоянных по формату) - уже проблема.

← →
Empleado © (2007-02-15 14:05) [5]

> Sergey13 © (15.02.07 13:51) [4]
> Конвертация 1 источника может и вправду не так сложна, а
> вот многих (и наверное не всегда постоянных по формату) - уже проблема.

Совершенно.
Именно это - привидение разных отличных друг от друга форматов данных к одному общему, с последующим использованием только его - и есть моя цель :)

← →
Sergey13 © (2007-02-15 14:09) [6]

> [5] Empleado © (15.02.07 14:05)

Ну так и проектируй СВОЙ справочник, кторый ТЕБЕ нужен. При этом конечно ИМЯ В ВИДУ послудующую конвертацию. Т.е. иди от своих потребностей, а не от форматов источников.

← →
Игорь Шевченко © (2007-02-15 15:38) [7]

> Все специфичные характеристики (например, %-ное содержание
> золота в часах, уровень радиоактивности молока, диаметр
> боеголовки) описаны в других таблицах - см. ItemFeatures1
> и CatItemFeatures1.

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

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможноЮ возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт "Эффективное проектирование приложений Oracle"

← →
MsGuns © (2007-02-16 08:30) [8]

>"Не используется словарь данных и метаданные. Те, кто применяет универсальный подход, загоняют себя в угол."

Весьма спорное утверждение

← →
Клара (2007-02-16 09:02) [9]

> MsGuns

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

>Клара (16.02.07 09:02)
С господином Кайтом. :)

Спасибо всем принявшим участие.

> хорошо известно, что можно представить любой объект в базе
> данных используя только четыре таблицы:

это провокационное утверждение, лишающее программистов рабочих мест -)

Концептуальный вопрос по архитектуре БД "Каталог" Найти похожие ветки