| full_lamer |
| Отправлено: 21.01.2005, 15:59 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
доброго времени
хочу поднять тему по оптимальному проектированию БД и написанию приложений работающих с ними. а именно:
целесообразно ли проектировать большие БД с большим числом таблиц и др. объектов, или же проще и удобнее создать несколько БД и время от времени обновлять данные. я к тому вопросу — что обычное среднее предприятие содержит от 3-4 БД (от банальных конфигураций 1С до всякого рода финансовых и вспомогательных программы типа "Налогоплатильщик 200Х" (от ПФР) и программ от МНС). я думаю стоит ли вести одну большую базу на предприятии, а в подразделения просто ее реплицировать, или же для каждого подразделения завести БД учитывая ее определенные требования.
зы. в общем то я уже определился, но просто хотелось бы услышать кто что думает и кто как работает, для общего развития.
спасибо за внимание.
|
|
| olegenty |
| Отправлено: 21.01.2005, 16:30 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
1. то, что это должна быть БД с единой структурой — факт (чисто управленческий... идеальная БД + софт к ней покрывают ВСЕ функции предприятия)
2. для себя остановился на распределённой БД, т.е.
2.1. на предприятиях есть БД с идентичной структурой
2.2. на БД прикручивается сервер приложений
2.3. на каждом предприятии клиенты ломятся на этот сервер
2.4. сервера взаимодействуют между собой и при
2.4.1. наличии необходимости
2.4.2. наличии прав на использование объектов
получается сквозная такая штука.
одно плохо: такую структуру я ещё успел реализовать. находится на стадии проекта, на который пока денег не дали.
|
|
| full_lamer |
| Отправлено: 21.01.2005, 16:32 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
а какие каналы связи используешь?
далеко расположены подразделения?
у меня тоже проект назревает — общую большую едину БД по всем аспектам предприятия и оптимизировано для нашего предприятия. вот думаю как лучше организовать — репликациями или еще как...
Отредактировано full_lamer — 21/01/2005, 17:37
|
|
| AVC |
| Отправлено: 21.01.2005, 16:51 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Сечас используется такой вариант
Головное предприятие решает разные задачи используя одни сервер БД.
Ближние подразделения (пока одно, как раз сейчас подключаем) работает с тем же сервером.
С дальними будем пробовать обмениваться только итоговыми выборками или репликации (пока в проекте).
Сервер приложений совмещен с сервером БД и как таковой отсутствует. |
|
| full_lamer |
| Отправлено: 24.01.2005, 11:36 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
а как например решать проблему распределения данных. например:
аппарат управления: имеется доступ ко всем данным;
гараж: нужен только список сотрудников и список автотранспорта;
склад: нужен только список сотрудников и список ТМЦ.
для каждого подразделения делать свой отдельный клиент или написать один общий — использующий мета-описания для форм и элементов интерфейса, и просто ставить его и передавать только мета-описания (по аналогии с 1С).
как Вы решаете эти проблемы.
Отредактировано full_lamer — 24/01/2005, 12:38
|
|
| olegenty |
| Отправлено: 24.01.2005, 11:49 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
связь по TCP/IP, основные подразделения-изготовители комплектующих — выделенка, сервисные центры — вероятно модемная связь. ещё один фокус — в основных подразделениях СУБД (вероятнее всего) MSSQL, сервисные цетнтры — однозначно FB. так что однозначно рулить всем этим будут сервера приложений в подразделениях. единственное, что будет гарантировано мной, как постановщиком (и разработчиком) и группой разработки — передача данных в едином для объекта формате. естетсвенно и специфичные типы данных по возможности использоваться не будут. а если да, их корректным превращением в локальный для СУБД подразделения формат будет заниматься сервер приложений подразделения, в зависимости от того, с какой СУБД работает (выполняя преобразование из единого формата передачи в локальный формат СУБД подразделения).
|
|
| AVC |
| Отправлено: 24.01.2005, 12:26 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Один сервер. Пользователь работают непосредственно с сервером БД через клиента. Один общий универсальный клиент. Права розданы на сервере. Клиент сам подстраивает себя под права, работающего с ним пользователя. Аналогично с запросами (формами, отчетами) — все описания и правила взаимодействия / переходов на сервере. Клиент зачитывает и настраивает себя.
Так как правила и права на сервере, то, в общем случае, пользователь может работать через что угодно. Наш клиент предназначен только для удобства.
|
|
| full_lamer |
| Отправлено: 24.01.2005, 12:31 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
| QUOTE | | Аналогично с запросами (формами, отчетами) — все описания и правила взаимодействия / переходов на сервере. |
| QUOTE | | Так как правила и права на сервере, то, в общем случае, пользователь может работать через что угодно. Наш клиент предназначен только для удобства. |
а в каком виде представлены правила и описания? тоже храняться в БД? или для них используется отдельные файлы описаний?
|
|
| AVC |
| Отправлено: 24.01.2005, 13:36 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
в каком виде представлены правила и описания? тоже храняться в БД?
|
Конечно. Это Blob поля (CLob/Memo/...) специальных таблиц.
Для описания используется, в основном, язык SQL. |
|
| full_lamer |
| Отправлено: 25.01.2005, 09:34 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
а например имена таблиц, хп, функций, полей каким образом присваиваются? автоматически с ведением мета таблиц:
("таблица работники" — tab001 (tab001f001, tab001f002, ...), ...)
или же логические имена
(employers (id, fname, lname, ....), ....
спасибо.
|
|
| AVC |
| Отправлено: 25.01.2005, 09:59 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
а например имена таблиц, хп, функций, полей каким образом присваиваются? автоматически ... или же логические имена ...
|
У меня — логические имена. Это же не система автоматического построения базы данных. Все таблицы, sp и прочее прорабатываются "вручную" — следовательно имена "с человеческим лицом".  |
|
| full_lamer |
| Отправлено: 25.01.2005, 10:25 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
| QUOTE (AVC @ 25/01/2005, 11:01) | | У меня — логические имена. Это же не система автоматического построения базы данных. Все таблицы, sp и прочее прорабатываются "вручную" — следовательно имена "с человеческим лицом". |
это все конечно понятно... удобнее работать с логическими именами. но я например последнее время избрал стратегию автоимен — правда пока еще эксперементирую: просто веду параллельно с разработкой БД таблицу имен. вообщем то удобно — заодно принудительно происходит составление инструции разработчика — на случай моей дезактивации  ... правда волокиты больше... но это пока эксперимент...
|
|
| AVC |
| Отправлено: 25.01.2005, 11:00 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Система автоматического, именно автоматического а не автоматизированного, построения системы таблиц, запросов и т.д. отпала на этапе предварительного обсуждения из за черезмерной громоздкости и трудности обслуживания для решаемых задач.
Как показывает мой опыт написать громоздкий запрос с разными нюансами опытному человеку проще, чем заставить это сделать автоматическую систему.
(Вместо правил синтаксиса и имен полей/таблиц приходится помнить правила настройки системы построения — объем информации зачастую увеличивается)
Неплохой результат дают системы с первичной автоматической генерацией запросов и "доводкой" их руками. |
|
| olegenty |
| Отправлено: 27.01.2005, 08:02 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 AVC — вот мне такой вариант, как у тебя, оч. нравится, но никак он у меня не получается: разные производители не договорятся о хранении своих данных физически на одном серваке )).
от всяческих репликаций/выгрузко-загрузок отказался сразу — никак не определить, какие данные отжно отдать, а какие нет. получается только сервер приложений.
|
|
| full_lamer |
| Отправлено: 27.01.2005, 11:34 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
2olegenty
прошу прощение — я не совсем понял что ты имеешь в виду... такого вроде бы в ответах не было... или я опять чего-то не понял...
|
|
| avc* |
| Отправлено: 27.01.2005, 12:28 |
|
Не зарегистрирован
|
| QUOTE |
разные производители не договорятся о хранении своих данных физически на одном серваке
|
А мы пока пользуемся преимуществом центральной конторы и навязываем подразделениям нужный нам способ. А кроме того из за специфики производства (энерго передающая компания) львиная доля запросов — просто просмотр. |
|
| olegenty |
| Отправлено: 27.01.2005, 16:54 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 AVC — нам хуже. мы собираем автомобили, а нам, скажем, поставляют двигатель. и поставщик даже на просмотр глубины двигателя не отдаст...
хотя вариант влезания вглубь будет предусмотрен, при наличии договорённости.
а нужно это для осуществления сервисного обслуживания в случае наличия договора у сервисного центра и на осуществление ремонта двигателя (помимо автомобиля в целом)
2 full_lamer там был небольшой оффтопик. но вроде по теме.
|
|
| AVC |
| Отправлено: 27.01.2005, 18:08 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
olegenty Могу посочуствовать.  |
|
| full_lamer |
| Отправлено: 28.01.2005, 10:32 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
2olegenty — прошу прощения — просто не обратил внимания.
а Вы часто даете команду собирать статистическую информацию и команда dbcc shrinkdatabase?
кстати на Ваших предприятиях стоят БД документов? если да то какие? имеет ли смысл вести свою БД документов?
|
|
| olegenty |
| Отправлено: 29.01.2005, 08:23 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
заключен договор с Московской фирмой Софтинтегро на поставку ДокМенеджер. это плагин к Outlook (гуд для секретуток) + BPM на ЖЦ документа + БД по документообороту. вчера наконец-то познакомился с разработчиками и продуктом лично. дёшево и сердито. фирма наша, выпускники МИФИ (если не ошибся) собрались и стали писать софт. короче — чтобы не писать самим — рекомендую. если не планируется интеграция документооборота в производство, то это самое то. а если планируется... я вам не завидую... у нас внуьри цехов и сеть-то... так себе... и тогда проект выльется в немеряные бабки на технические средства. делать это только ради документооборота, есс-но, никто не будет.
СофтИнтегро работает с КамАЗом уже поболее 2-х лет, мы, как я понял, неплохо отбетатестили их продукт, а они учли в продукте наши пожелания, что были высказаны в процессе тестирования. ну и все довольны. да, и разработчики оставили по себе ощущение компетентности. лично на меня мало от общения с кем остаётся такое ощущение.
внедрение стартанёт в апреле.
Stacey.Kruchkova@softintegro.ru — Анастасия Крючкова, нач. отдела маркетинга
msokolov@softintegro.ru — основной разработчик
www.softintegro.ru — очевидно официальный сайт.
|
|
| full_lamer |
| Отправлено: 29.01.2005, 09:44 |
|
Машинист паровоза
Группа: Участник
Сообщений: 225
|
2olegenty
это конечно большое спасибо за справку. я знаю просто 1С тоже предлагает подобное решение, которое интегрировано с оффисом, да моему и сама Микрософт тоже чтото подобное выпустила... проблема в том что часть документов очень тесно связана с производством...
но все равно спасибо за наводку.
|
|
| olegenty |
| Отправлено: 29.01.2005, 10:54 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
под "в производство" я имел в виду, что эта штука не интегрируется с PDM, т.е. цикл разработки КД->ТД->Подготовка производства не охватит вкупе с обслуживающей PDM CAD/CAE системой разработку документа (чертежа и технологической документации к нему). хотя сам цикл прохождения документа от конструктора на рабочее место у станка легко формализуется и автоматизируется ДокМенеджером (т.е. от кого кому дальше, что именно и в каком виде — это без вопросов. кому разослать после утверждения — тоже не вопрос, это делается на уровне управления бизнеспрцессом, где, в этом случае, бизнеспроцессом является жизненный цикл документа).
|
|
