Оптимальная архитектура БД

Здравствуйте!

Написал базу (в общеобразовательных целях). Таблицы: Company, Person, Good,... куча справочников. Базу нормализовал, разработал тестовые приложения, проги для заполнения справочников.

Теперь, собственно, вопрос.
Как лучше организовать доступ к базе? Есть такое решение ("подсмотренное" у других): наряду с "обычными" таблицами БД, сделать еще и "форматные", т.е. те же самые по структуре, но с приставкой "F": Company-FCompany, Person-FPerson... etc. В каждую форматную таблицу добавить поле ID_Query (идентификатор запроса). Т.о., когда клиент запускает запрос, параметры запросы он ложит в форматные таблицы, оттуда же достает результат. Результаты "его" запроса отличаются от других результатов - по разным ID_Query (при формировании запроса, каждый получает свой ID). Естественно, база при работе переносит данные из "обычных" таблиц в форматные и обратно, СП "чистит" форматную часть БД от данных "умерших" клиентов и т.п.
Через провайдеры клиент "видит" только свои данные (с нужным ID_Query).

Является ли такая структура оптимальной? Или есть другие варианты построения БД? (Чтобы можно было отличать данные разных клиентов и т.п.) Использовать ли только DCOM/MIDAS (кажется, только у них есть провайдеры)? Т.к. хочу всё это хозяйство написать на CBuilder с CORBA, какую работу будет выполнять CORBA - только интерфейс СП(реализация методов) или можно как-то еще увязать ее с провайдерами, созданием бизнес-объектов на сервере и т.п.? Может есть у кого-то ссылки на сабж? (желательно, с технологиями, упомянутыми в PS: - см. ниже)

PS: Просьба не превращать топик во флейм "CBuilder vs Delphi", "CORBA vs DCOM", etc. Примем как факт: MSSQL2000 (DBMS), CBuilder (среда), CORBA (транспортный протокол), ADO (доступ к данным на клиенте), Rational Rose (бизнес-моделирование, модель классов СП, интерфейсы IDL)

PPS: Не так давно задал вопрос на форуме: "Как отписаться от темы?". Может сейчас кто-то ответит?

мало иноформации для ответа на ваш вопрос.

Ох как у Вас все в кучу свалено... Не удивительно, что sparrow пожаловался на недостаток информации.

Заголовок топика и его начало - про архитектуру.
Середина - про права доступа
Окончание - про клиентов

И ни на один из этих вопросов нельзя дать ответ, что мол, вот если сделать так, то система будет оптимальна.
А что такое оптимальна? Оптимальна с точки зрения скорости работы? Безопасности? Скорости написания? Удобства апгрейда? Нет рецепта по написанию базы, оптимальной во всех отношениях. Что вовсе не означает, что для конкретной задачи нельзя написать эффективную базу. Я бы лучше пользовался таким словом.

Теперь про форматные таблицы. Перемудрен огород. Ограничение доступа для разных юзеров можно сделать проще и эффективнее. У меня такое впечатление, что виденная Вами база является унаследованной от какой-то БД последовательного доступа, не поддерживавшей разграничения прав доступа. Впрочем, это могла быть и попытка написать объектную БД.

Запросы от каждого юзера отличаются друг от друга тем, что в них всегда можно проверить user_id() и определить от кого запрос. Или host_id(), для проверки машины.

На чем писать - а на чем больше нравится.
Куда выносить бизнес процессы - а фиг его знает. Тут действительно нужно знать конкретную задачу.

А зачем эти F-таблицы?!!!
Дергай х.п-ры и будь счастлив.

1-й вариант (Использование View)

create table FilterClassCreationLayer ( SPID int not null default (@@SPID), BaseClass varchar(16) not null, constraint PK_FilterClassCreationLayer primary key clustered(SPID, BaseClass) ) go create view FilterClassCreation with SCHEMABINDING as select BaseClass from dbo.FilterClassCreationLayer with (nolock) where SPID = @@SPID go

2-й вариант - использование временных таблиц

ОК. Действительно, сумбурно как-то получилось.

Итак, по-порядку:

1) Как построить базу, чтобы можно было выполнять запросы/ХП/смотреть вьюшки, и: результат запроса одного клиента отличался от рез-ов другого? 2Тимур: F-таблицы для того и нужны, чтобы данные копировались из "обычных" таблиц в F-таблицы, причем записи в F-таблицах под разным ID_Query. Дальше провайдер на СП возвращает данные типа: SELECT * FROM F_TABLE1 WHERE ID_Query=заданному клиентом (и клиент видит только свои данные).

2) как строить СП: просто куча провайдеров, возвращающих данные (см. п.1) или к-л другим образом (бизнес-объекты?). Методы СП просто дублируют вызов ХП/селекты из БД или делать те же бизнес-объекты со встроенной обработкой бизнес-правил ИС?

3) Критерий оптимальности: быстрота написания, легкость сопровождения/изменения (т.е. БД-только SQL-запросы, ХП и т.п. - никакой бизнес-логики!!!; СП-транспорт, обработка бизнес-правил; Клиенты-интерфейс доступа к данным, опять же никакой логики и SQL-запросов, все на вызовах ХП, методов AppServer-а)

4) используемые компоненты для сервера и клиента.

По пункту 1.

Создаем таблицы

objects (userID int ,ObjectID int , ObjectName)
Detail (ObjectID int, param1, param2, param3 )

Предположим, в таблице хранятся данные по разным объектам. Каждый юзер может работать только с одним из них.

Запрос

select * from Detail join objects
on Detail.ObjectID=Objects.ObjectID
where userID=user_id()

вернет данные только по назначенному для него объекту

Чего-то, толи лыжи не едут, толи .... :))

Зачем вообще вот это 1) Как построить базу, чтобы можно было выполнять запросы/ХП/смотреть вьюшки, и: результат запроса одного клиента отличался от рез-ов другого? 2Тимур: F-таблицы для того и нужны, чтобы данные копировались из "обычных" таблиц в F-таблицы, причем записи в F-таблицах под разным ID_Query. Дальше провайдер на СП возвращает данные типа: SELECT * FROM F_TABLE1 WHERE ID_Query=заданному клиентом (и клиент видит только свои данные).

Объяснения не нахожу.

Откуда доступ к БД вообще производится? Из инета, по локалке, или как еще?

3) Критерий оптимальности: быстрота написания, легкость сопровождения/изменения (т.е. БД-только SQL-запросы, ХП и т.п. - никакой бизнес-логики!!!; СП-транспорт, обработка бизнес-правил; Клиенты-интерфейс доступа к данным, опять же никакой логики и SQL-запросов, все на вызовах ХП, методов AppServer-а)

Исходя из этих критериев, средний слой вообще следует исключить - дублирует сервер.


Да и не понятно, ЧЕГО ДЕЛАЕШЬ то вообще???????

> Объяснения не нахожу.
> Откуда доступ к БД вообще производится? Из инета, по локалке, или как еще?
Доступ по лок.сети. Объясню подробнее. Клиент на форме выбирает: показать все компании по критерию: дата регистрации после 01.01.2002. Дергает ХП - HandleQuery(12) (12-й запрос выбирает компании с заданным критерием). СП передает запрос базе и та копирует найденные компании из обычных таблиц в форматные с проставлением нужного значения ID_Query (уникально - генерируется клиентом). Дальше, с помощью провайдеров СП, клиент "видит" записи в форматных таблицах со "своим" значением ID_Query. Т.о. в своих ClientDataSet-ах клиент всегда получает данные только "своих" запросов.

Является ли такая схема оптимальной? Или есть к-л другие варианты отображения результатов запросов клиентам? Очень хотелось бы, чтобы решение было прозрачным (т.е. без излишних напрягов в коде, типа создания временных таблиц для каждого запроса, пул клиентов/запросов и т.п., т.е. аналогично провайдерам DCOM-а, но под CORBA).

> Исходя из этих критериев, средний слой вообще следует исключить - дублирует сервер.
Как раз сервер бы очень хотелось бы иметь - для хранения в одном месте бизнес-правил (БП). Если видов клиентов несколько, то искать потом и синхронизировать БП на каждом из них (например, что дата регистрации компании не может быть больше текущей даты) - не самое умное решение.

> Да и не понятно, ЧЕГО ДЕЛАЕШЬ то вообще???????
В общеобразовательных целях, т.е. для повышения квалификации делаю БД, сервер приложений и клиента к нему.
Квалификация, она всегда пригодится ;-)

Ну, по-порядку....
Доступ по лок.сети. Объясню подробнее. Клиент на форме выбирает: показать все компании по критерию: дата регистрации после 01.01.2002. Дергает ХП - HandleQuery(12) (12-й запрос выбирает компании с заданным критерием). СП передает запрос базе и та копирует найденные компании из обычных таблиц в форматные с проставлением нужного значения ID_Query (уникально - генерируется клиентом). Дальше, с помощью провайдеров СП, клиент "видит" записи в форматных таблицах со "своим" значением ID_Query. Т.о. в своих ClientDataSet-ах клиент всегда получает данные только "своих" запросов

Объясни тогда, зачем такая маразматическая схема? Чем плохо дернуть процедуру и показать результат?

Является ли такая схема оптимальной? Или есть к-л другие варианты отображения результатов запросов клиентам? Очень хотелось бы, чтобы решение было прозрачным (т.е. без излишних напрягов в коде, типа создания временных таблиц для каждого запроса, пул клиентов/запросов и т.п., т.е. аналогично провайдерам DCOM-а, но под CORBA).

Схема страшно неоптимальная и непонятно зачем придуманная
Почему обычный вывод из ХП - нестандартный для тебя.

Как раз сервер бы очень хотелось бы иметь - для хранения в одном месте бизнес-правил (БП). Если видов клиентов несколько, то искать потом и синхронизировать БП на каждом из них (например, что дата регистрации компании не может быть больше текущей даты) - не самое умное решение.

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

Я как раз и написал, что сервер следует оставить а выкинуть средний слой - объясни, зачем он тебе?

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

Нда, ну и квалификацию приобретешь с такой архитектурой