Суть проекта :

- имеется БД в административном центре, в которую стекается
информация с подчиненных подразделений.

-Информация в подчиненных подразделениях так же хранится
в БД, расположенных локально на машинах пользователей.

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

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

- среда реализации клиентской програмы C#, VS2008

Особенности и требования :

- Объем базы в центральной БД - миллионы записей, ежемесячно пополняется на 5-10 тысяч записей (это информация,
собранная со всех подчиненных подразделений)

- очень сильно вероятны возможности изменений в структуре БД - добавление новых полей, новых справочников

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

Вопросы, по которым хотелось бы услышать советы и комментарии :

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

пример для лучшего понимания мысли :

плоская таблица :

(таблица ЧЕЛОВЕК)
-------------------------------------
Фамилия |Имя | Отчество | возраст
-------------------------------------
Иванов |Иван | Иванович | 25
Петров |Петр | Петрович | 15
Сидоров |Сидор | Сидорович | 29


Гибкая структура :

(таблица ПАРАМЕТР)
-----------------------------------
id | параметр | тип данных
-----------------------------------
1 | Фамилия | nvarchar
2 | Имя | nvarchar
3 | Отчество | nvarchar
4 | Возраст | int

(таблица ДАННЫЕ)
--------------------------------------------
id | id_param | nvarchar_value | int_value |
--------------------------------------------
25 | 1 | Иванов | |
26 | 2 | Иван | |
27 | 3 | иванович | |
28 | 4 | | 25 |
29 | 1 | Петров | |
30 | 2 | Петр | |
31 | 3 | Петрович | |
32 | 4 | | 15 |
33 | 1 | Сидоров | |
34 | 2 | Сидор | |
35 | 3 | Сидорович | |
36 | 4 | | 29 |


Вопрос - как такая организация БД отразится на быстродействии? Если отразиться, то насколько принципиально?

2) Какую СУБД выбрать для БД административного центра. Варианты MSSQL 2005 и Oracle
3) Какую СУБД выбрать для БД подчиненных подразделений. (XML, SQL Expres, Access, ваш вариант)
4) какой механизм выгрузки данных из подчиненных подразделений в административный центр посоветуете
(сериализованный DataSet, XML, сериализованная объектная модель, отражающая стуктуру БД, ваш вариант)
5) Какие механизмы посоветуете использовать при разработке клиентской части (Linq, ADO, ваш вариант)

Буду очень благодарен за высказанные мысли

Есть у меня опыт работы с такими БД (Я надеюсь, что Вы упростили все-таки идею).


Вы про таблицу в примере?

Смотря как будет использоваться БД. Если основное её назначение просто накапливать данные, то не очень сильно это на производительности скажется.


В том и дело, что с базой будут работать - доставать информацию, делать отчеты...

А вот доставать данные из такой БД это кошмар реальный. Т.е. если планируется, что кто-то в режиме реального времени будет эти данные просматривать, анализировать и т.п., то рассчитывайте на очень серьёзные, вплоть до полного провала, проблемы с производительностью.

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

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

Hauermrakk,

Причины... Так в двух словах и не опишу. Я, скорее, просто из опыта. Это увидеть надо.

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

шаг 1:
SELECT id_info FROM data_table WHERE int_data ляля AND id_param = 99

где
id_info - идентификатор, по которому объеденена вся единица "поступившей информации"
99 - идентификатор параметра "возраст"

список id_info c в datatable или еще в чем-нибудь поступает в клиент

шаг 2:

в клиенте тыкаем по нужной информации и получаем уже все что по ней есть :

SELECT * from data_table WHERE id_info = ляляля

-----

очень грубо говоря - я так себе примерно представлял... пока вы меня не расстроили )))))

HauerНе, давайте чуть поточнее - вот жирный текст, нужная информация это id? Я как-то представлял себе пользовательский интерфейс это как список с хотя бы минимальным набором полей типа "ФИО", "дата рождения",... Даже, возможно, с сортировкой по этим полям.


Ну да... как-то я сумбурно описал

Если допустить, что главная (объединяющая другие) сущность это "человек" с атрибутами типа ФИО, год рождения, а все остальные сущности к ней привязаны - сведения о месте работы, сведения о домашнем адресе и т.д, то :

1) по атрибутам, по которым осуществляется поиск (а осуществляться он должен по любым из них) селектируем список идентификаторов главной сущности

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

3) по запросу из клиента - селектируем все остальные атрибуты всех сущностей, имеющиеся в нашей большей таблице для одного, выбранного в клиенте, идентификатора

если при таком подходе все будет очень медленно - то со структурой вопрос снимается. будем делать плоскую структуру

И давайте сразу дальше вопрос (следующий шажок) - у Вас (логически) ведь не одна сущность? И они, наверное, между собой связи имеют. Вот, например - адрес человека, ну или там место работы (отдел). Эти связи Вы как селектировать планируете?
И сразу еще один вопрос - а что мы планируем делать с ссылочной целостностью?[/quot]

наверное, все-таки убедили ))) и спасли от горькой ошибки ) спасибо