Уважаемые проектировщики, программисты и сопроводители баз данных (БД)!

Осознавая недостаток практического опыта в данной области, я всё-же решился создать топик.

Небольшое отступление.
1. Сразу хочу извиниться за размер поста – хотелось подробнее описать предметную облать, дабы избежать разбросанности вводной информации по веткам топика.
2. Давайте уважать время и мнения друг-друга – не надо войн типа "Windows vs Unix", "Oracle vs MSSQL", "ЕК vs СК" и т.д. и т.п. Интересны ответы – "я бы сделал так-то (по таким-то причинам)".
3. Проект не коммерческий (в том плане что " заказчик " не ставит целью извлечение материальной прибыли – продукт для распостранения, но не для продажи). Но возможен вариант передачи проекта на реализацию фирме.
4. Проект достаточно сложный и потому интересный (по-поему мнению).

Итак.

Общая постановка.

В ряде стран (в основном потомки СССР), есть люди называющие себя "поисковиками" (не путать с интернет-поисковиками). Они занимаются установлением судеб погибших, пропавших без вести и репрессированных в годы ВОВ. (для пояснения: человек погиб в бою. Данные не занесли в списки потерь личного состава, или "похоронка" не дошла – родственникам неизвестна его дальнейшая субьба).

Эта работа проходит с двух разных сторон:
1. Родственники (или те люди кто ищет человека) просят: "помогите найти деда – такого-то такого-то, у нас есть такие-то данные о нём".
Т.е. установление судьбы – что стало с человеком, если умер/погиб – где и когда, где захоронены останки.
2. "Поисковики" в ходе экспедиций на местах боёв ВОВ находят останки солдат, при которых могут быть "личные вещи" - несущие информацию о владельце и/или родственниках.
Т.е. поиск родственников.

В обоих случаях:
- производится поиск по уже имеющимся данным;
- проверяются наличие сведений в Книгах Памяти, изучаются входящие донесения частей и т.п.;
- делаются "запросы" в архивы (например ЦАМО – Центральный Архив Министерства Обороны) с просьбой предоставить сведения о таком-то человеке.
В первом случае результаты работы отсылаются родственникам ("нам удалось установить то-то").

Что имеем:
1. Куча разрозненной, неструктурированной информации в различных видах: как бумажной (письма родственников, ответы архивов и пр.), так и электронной (от текстовых файлов появившихся в результате сканирования, до различных баз – Excel, Access, dBase и т.д.).
2. Понимание и желание навести в этом деле порядок – постоить централизованную систему по сбору и обработке информации.

Какое это имеет отношение к данному сайту? – Помогите :)
Надо спроектировать структуру БД. Не прошу примеров и не переваливаю свою головную боль на вас, просто прошу советов.

Учесть (не по степени важности):
1. Распостраняемость.
Можно выделить центр и региональные представительста (Издатель-Подпиcчики). Они равноправны - в каждом представительсте изменяют "свои" и читают "чужие" данные, центр лишь объединяет и распостраняет (планируется раз в квартал, в виде CD).
2. Расширяемость.
Кроме решения насущных и первостепенных задач необходимо предусмотреть возможность расширения. Так, планируется использование геоинформационных систем (ГИС) и цифровых карт (местность, укрепления, залегание останков и т.д.); использования математического аппарата для работы с нечёткой и неполной информацией – надстройки в виде системы поддержки принятия решений (СППР), ну если грубо – "с какой вероятностью останки человека N принадлежат искомому".
3. Трудозатраты и целесообразность.
Занимаются этим скорее "энтузиасты", в основном не получают за это деньги. И скажем "набивать руками" справочник административного деления представляется делом сомнительной необходимости. Уже есть данные в электронном виде, их достаточно много. Скажем Книга Памяти Республики Татарстан – 424.000 записи. Конечно их надо уметь импортировать, экспортировать.

4. Быстродействие.
Думаю пояснять не надо.

+ Не надо требовать от конечных пользователей каких-то дополнительных знаний, как-то: теории построения реляционных баз данных, языков (SQL) и т.п. Даже работа администратора регионального представительста должна сводится к : "запретить работу пользователей с БД", "подготовить данные для передачи в центр" и т.д.

+ по всем основным видам деятельности должна вестись статистика/аудит, например:
сколько установлено людей; сколько обработанно запросов родственников; сколько отправлено запросов в архив, получено ответов; сколько поднято останков, найдено именных вещей и т.д. - за период времени, по административной единице, по исполнителю (пользователю).

Думаю теории за глаза.

Пока без объяснения причин:
- СУБД – MSSQLServer2000;
- толстый клиент – Windows приложение (думается .NET, C#) – для сотрудников, вся работа выполняется здесь;
- тонкий клиент – браузер, для всех желающих поискать, почитать.

Вопросы по этой части:
1. Насколько осуществим такой проект? Есть подобный опыт? Где посмотреть пример, почитать как делали?
2. Стоит ли вести этот проект своими, очень малыми силами или лучше передать дело профессионалам?
3. Примерные сроки реализации и стоимости основной функциональности? (хотя наверно задача описана слишком в общем)
4. Хватит ли возможностей выбранной СУБД для поставленной задачи?
5. Есть ли желающие в этом учавствовать? В какой форме? Что за это хотите?

Если тема вызовет интерес – есть много практических вопросов. (без всей этой воды)

P.S. Лично я занимаюсь этим потому что сам из этих "поисковиков" и считаю делом хорошим и нужным людям, осмелюсь назваться программистом (показать могу только www.ipc.antat.ru хотя мне не всё там нравится), считающим что он сможет внести свой вклад, и потратить на это год, два своей жизни. Мне это интересно в плане опыта: не каждому выдаётся шанс поучавствовать в проекте такого уровня.

P.P.S. Прошу извинения за возможные задержки с ответом – что-то у нас в последнее время частенько канал падает :)

Хм...
Никому не интерсно? Никто не знает?

Или пятница не тот день для таких вопросов ? :)

Вообще вопрос не стоит за бесплатно. Что вы предлагате, и что за это хотите?

:)

Постараюсь уточнить.
Вообще-то реализовать могли-бы многие, и думаю я тоже :) Всё дело лишь том как, за какое время и за какие деньги.

Т.е. при моей ЗП в 4.000 руб/мес - что лучше платить человеку два года = 96000, или отдать их компании которая сделает это с официальными бумагами за год. Что мол заказчик - то-то и то-то, исполнитель - вот это. Всё оговорили, все довольны.
(Цифры условные, и я не совсем уполномочен о них говорить).

Не подвергаются сомнения Ваши способности, но фраза
авторуниверсальная структура на все мыслимые случаи лично меня пугает :))

Могу я считать что по вашему мнению - задача вполне реальная и решаемая?

Большое спасибо за ответ! Покажу цифру босу :)

Таких денег нет :)

Отсюда два вывода:
1. Думаю мы друг-друга поняли ?
2. Придётся заниматься этим своими силами.

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

Ну а на счёт с нуля...
Если бы на данный всё это дело только начиналось (читаем с нуля), мне было-бы проще. Не надо тянуть за собой старые форматы и данные, их конвертацию и т.п. Да и досталось-бы что-то не доделанное или сделанное через Ж - пришлось бы ещё и в том разбираться, оценивать насколько это работоспосбно, и как вариант - начинать с нуля.

Забыл сказать:
не смотря на то что значения web'а растёт (и у нас в стране), сайт для этого дела, позиция далеко не первая. Это чисто презентативный уровень/интерфейс для простых людей. Хотя, признаюсь, есть наши попытки наладить сбор информации по именным находкам экспедиции через Инет.
Не нравится и людям, и разработчикам.

Я так думаю что Вас я прекрасно понял.

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

Для того чтобы "знать" хотя-бы на уровне школьницы - я сюда и обратился.

На счёт $ - всё больше убеждаюсь что делать предётся самим.

Не сочтите за грубость - мне кажется мы немного отвлеклись от темы. Что-то больше на философию тянет...

А практические вопросы (коль делаю я) достаточно разные (то что касается БД):
1. как организовать административное деление? (тема поднималась на многих сайтах)
Любая адм. единица может входить в заранее неопределённое количество других единиц - т.е. если по России можно постоить цепочку Страна, регион (субъект РФ), район, сельсовет(волость), нас. пункт то сказать как там всё устроено скажем в Польше (условно) нельзя. Я пробовал делать в виде таблицы с циклическими ссыками типа (упрощённно):
| ID | Title | Type | Rank |Parent_ID |
-------------------------------------------------|
| 1 | Россия | страна | 0 | null |
| 2 | Татарстан | республика | 1 | 1 |

... и т.д

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

Причём можно было-бы обойтись и одним полем - address, но 1) нужны выборки по этим единицам, 2) нужно фильтр ввода - при заполнении адреса давать возможность выбора страны, далее республик в неё входящих и т.д.

Это то что касается современных адресов.

А ещё есть "старые" (времён войны) адреса.

Не очень превлекает реализовывать всю хронологию - кто, когда, куда входил + разные название одной и той-же единицы. Вот сейчас - Республика Татарстан, мои родственники из Рязани пишут в письме адрес как привыкли - Татария.
Или скажем нашли смертный медальнон - там всё водой размыло, сгнило и в графе республика видно ...ан. И хранить надо именно так. Может Татарстан, может и Узбекистан.

И вот таких интеремных задач много.

Добрый вечер!

И да, и нет.

ОМО Объединение Отечество этим занимается (я так сказать оттуда), этим занимается много организаций. Но с другой стороны - да. Мы работаем в рамках института ИПИ АН РТ, отдел социально-информационных систем.

Просто в институте много других направлений. Но мы так сказать денежки только "кушаем"...

TO softwarer:

Спасибо за Ваши ответы! Именно на такие и расчитывал - точно и по-делу.

Польза от обращения на данный форум уже ощутима - раскрывает глаза "заказчику" на стоимость и затраты времени. Вот только не возымело бы это обратного эффекта - скажут "да нафиг это надо", и будут по-прежнему запивать в поля MEMO целые страницы текста и мечтать и хорошей жизни :[

я не скрываю что не силён в базах, хотя прежде чем писать сюда и отвлекать людей конечно же читал. Есть разные мнения. Скажем один человек сказал примерно следующее (приверженец ООП): "можно абстрагироваться от структуры базы - создать просто одиночные таблицы без связей PK-FK, и делать всё программно." У него был такой проект, и я видел как он работает.
"Бывает приходится посылать всю или почти всю объектную модель и переходить к процедурному программированию, по простой причине - так быстрее работает, и иногда это принципиально."
А к чему это я? Сколько людей - столько мнений. Одно задание - много реализаций.
Вот и хотелось бы наметить путь.

TO guest_20040621:
ТЗ как такового нет (даже не знаю - смеятся или плакать), и составлять его придётся мне - "заказчик" не всегда может точно представить что и как он видет и хочет. Просто в этой тематике я достаточно давно и на 70 % могут ответить.

guest_200406211. Хронологичность данных (т. е., объекты базы данных имеют состояние, зависящее от временнЫх факторов)
ну не совсем так, хотя больше да чем нет. Кроме описанной проблемы адм. деления есть ещё по крайней мере один случай:
какая воинская единица (часть, рота, полк) в каком составе ( кто руководил ) куда входила на интервале времени. сейчас это просто текст.
и что интересно - можно в Word'де скажем нажать Ctrl+F - и найти скажем 122 СП.
Но это всё не на всём отрезке времени, а только "тогда". Хотя с другой стороны адм. деление может и сейчас поменяться - я слышал хотят объеденить некоторые субъекты РФ. Так что Вы правы.

guest_200406212. Мультиязычность данных;
не совсем понял. есть проблемы лексического характера, точнее транскрипции - скажем как записать по-русски фамилия с другого языка, ищеющего собтсвенные буквы/произношения. К примеру с татарского на раусский. И тем более как восстановить такую, записанную часто на слух фамилию.

guest_200406213. Синхронизация данных.
О Да !

softwarer...
Сложный вопрос. Думаю, оптимальным для Вас будет некоторое среднее решение - найти грамотного человека, который набросает "скелет" и согласится консультировать дальнейшую разработку собственными силами.
...

Вот и тоже придерживаюсь такого мнения.

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

Пока такого не встречалось. Теоретически возможно.

Извините за мой русский :) описки.

Спасибо всем! Думаю на принципиальные вопросы я ответ получил.

(Но это не значит что хотел бы закрыть тему)

NuriahmetovЗабыл сказать:
не смотря на то что значения web'а растёт (и у нас в стране), сайт для этого дела, позиция далеко не первая. Это чисто презентативный уровень/интерфейс для простых людей. Хотя, признаюсь, есть наши попытки наладить сбор информации по именным находкам экспедиции через Инет.
Не нравится и людям, и разработчикам.

тут меня поправляют:

<<
не "не нравится", я такого не слышал, а не у всех есть техническая возможность набивать, или нет времени
>>