Мозговой штурм на тему разработки клиент-серверного приложения

← →
DevilDevil © (2012-12-27 12:12) [0]

Здравствуйте уважаемые форумчане

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

Итак задача у меня - организовать многопользовательскую систему (человек 30) с доступом к общим данным. У каждого пользователя будет клиентское приложение, которое будет обращаться к серверу (сервер мне выделят). Пользователи будут оперировать общими данными (БД) и файлами. У нас лицензия и спецы на MS SQL Server (будет либо 2005, либо 2008). У каждого пользователя есть права (среди которых административные).

Соответственно появляется много вопросов:
1) можно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БД
2) какие компоненты и библиотеки нужно использовать для работы с MS SQL Server
3) каким образом принято разграничивать права пользователей

Соответственно появляется мысль, что нужно организовать серверное приложение, которое будет прослойкой между клиентом и базой данных с файлами. Тут ещё больше вопросов:
1) какими компонентами пользоваться для организации клиент-серверной архитектуры
2) каким образом организовать систему входа (логин/пароль) и определять права пользователей
3) как реагировать на разрыв связи и прочие неполадки с коннектом, как отлавливать
4) как организовать передачу файлов
5) как вообще обмениваться данными между сервером и приложением. тут ведь не просто строку надо передавать. тут более сложные механизмы

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

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

← →
DevilDevil © (2012-12-27 12:14) [1]

+ как грамотно реализовать автоматический апдейт клиентского приложения

← →
Ega23 © (2012-12-27 12:23) [2]

1) можно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БД
Смотря какой объём. Хранение файлов "во вне" ускоряет бэкап, но на порядок увеличивает проблемы с целостностью данных. ИМХО, нужно очень веское основание для того, чтобы хранить файлы "во вне".

2) какие компоненты и библиотеки нужно использовать для работы с MS SQL Server
Доступ ADO, для MSSQL это "родное". Компоненты для Delphi - TADOConnection, TADODataSet, TADOCommand. Есть нюансы при работе с BCD.

3) каким образом принято разграничивать права пользователей
Либо свою надстройку над "бизнес-действиями", с шахматами и поэтессами. Либо доменные учётки с соответствующими GRANT/REVOKE

← →
знайка (2012-12-27 12:23) [3]

> многопользовательскую систему (человек 30)
Разве это многопользовательская? :)

Что за файлы?
И кто вам сказал что их в бд не правильно?

> нужно организовать серверное приложение
веб сервер, и все дела...

← →
DevilDevil © (2012-12-27 12:29) [4]

> Ega23 © (27.12.12 12:23) [2]
спасибо

> Что за файлы?
> И кто вам сказал что их в бд не правильно?

ну там сканы документов всяких. А в чём хранить то, в BLOB-ах ?

← →
DVM © (2012-12-27 12:38) [5]

> DevilDevil © (27.12.12 12:12)

> 1) можно ли отделаться только базой данных. Мне сказали,
> что не правильно хранить файлы в БД

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

> 2) какие компоненты и библиотеки нужно использовать для
> работы с MS SQL Server

ADO как уже сказали. Лучше и не придумаешь.

> 3) каким образом принято разграничивать права пользователей

1) Самый простой и самый глупый вариант - разграничить права в клиентском приложении путем отключения частей интерфейса. Не надежный путь.

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

3) Разграничить права средствами базы. Способ надежный, но несколько неудобный и зависит от возможностей СУБД. Некоторые вещи, такие например, как разграничение доступа на уровне записей для некоторых СУБД не реализовать только этим способом.

4) Средствами СУБД + своя надстройка в виде отдельных таблиц с пользователями и их правами на отдельные действия ит.д. Это долго описывать, вариантов много, мне понравился вот такой вариант
http://gsbelarus.com/gs/modules.php?name=News&file=print&sid=358
и в одной из программ я его использовал. Но правда речь о Firebird.

← →
DVM © (2012-12-27 12:49) [6]

> DevilDevil © (27.12.12 12:29) [4]

> ну там сканы документов всяких. А в чём хранить то, в BLOB-
> ах ?

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

← →
DevilDevil © (2012-12-27 12:51) [7]

> DVM © (27.12.12 12:38) [5]

спасибо
а файлы в чём хранить ?
я слышал BLOB-ы имеют ограничение в 64кб

может примерчики по ADO кто подкинет ?

← →
DVM © (2012-12-27 12:52) [8]

> DevilDevil © (27.12.12 12:51) [7]

> я слышал BLOB-ы имеют ограничение в 64кб

да не, нет там ограничений

← →
DevilDevil © (2012-12-27 12:52) [9]

и не скажется ли это на производительности БД, если хранить в ней файлы

← →
DVM © (2012-12-27 12:55) [10]

> DevilDevil © (27.12.12 12:52) [9]

> и не скажется ли это на производительности БД

А на производительности жесткого диска сказывается, что ты на нем хранишь фильмы?

← →
Ega23 © (2012-12-27 12:59) [11]

> и не скажется ли это на производительности БД, если хранить
> в ней файлы

А они в куче базы хранятся, в таблице де-факто у тебя просто ссылка.

← →
DevilDevil © (2012-12-27 13:00) [12]

> DVM © (27.12.12 12:55) [10]

как то это слишком приятно звучит, что можно решить вопрос использованием только БД :)

← →
Jeer © (2012-12-27 13:04) [13]

> что можно решить вопрос использованием только БД

Грамотный народ это не напрягает, юзеров - тем более:)

← →
MsGuns © (2012-12-27 13:06) [14]

Прежде чем выбирать тип сервера и рещать "проблему с блобами", надо перво-наперво четко сформулировать ЦЕЛЬ и ЗАДАЧИ всего этого безобразия. После чего построить ИНФОРМАЦИОННУЮ МОДЕЛЬ предметной области, определить ДОКУМЕНТООБОРОТ и СУБЪЕКТОВ.
Без этого все будет похоже на то, как Петька с Васильиванычем фельдшерами в деревне работали (таблетка №9 если кто забыл)

← →
Ega23 © (2012-12-27 13:08) [15]

> как то это слишком приятно звучит, что можно решить вопрос
> использованием только БД :)

Мода на хранение файлов вне БД - это из Web-разработок, когда надо пользователю ссылку на файл в html пихать.
Больше никаких преимуществ не вижу. Зато недостатков - море.

← →
MsGuns © (2012-12-27 13:13) [16]

Вдогонку.
Само слово из сабжа "приложение" о чем говорит ?
А говорит оно о том, что есть некоторая СИСТЕМА, к которой прикладывается некоторый пользовательский функционал. Т.е. предполагается, что УЖЕ ЕСТЬ некоторая система.
У Вас же, как я понял, ветра гуляют и ничегошеньки нет. Никакой СИСТЕМЫ. О каком приложении речь тогда ? Вам нужно начать с системы. По аналогии со строительством - Вам нужно не стройматериалы закупать и котлован рыть и даже не чертежи чертить, а определиться для начала - ЧТО Вы хотите строить, для КОГО, в какое СРОКИ и за СКОЛЬКО денюх.

← →
tesseract © (2012-12-27 13:16) [17]

> Ничего зазорного в этом нет, уже обсуждали, плюсов множество,
> недостатки надуманные. База - такой же файл.

А файловая система - такая же база данных.

> 2) каким образом организовать систему входа (логин/пароль)
> и определять права пользователей

Оптимально - использовать доменную авторизацию. Если конечно домен поднят. Native Client в общем-то её поддерживает, ничего дописывать не придется.

> 5) как вообще обмениваться данными между сервером и приложением.
> тут ведь не просто строку надо передавать. тут более сложные
> механизмы

Файл - это набор двоичных строк. В чём проблема то ?

> В каких случаях нужно создавать справочники, как увязывать
> между собой сущности и т.д.

Расписать в UML схему базы. Оптимальный вариант.

← →
Медвежонок Пятачок © (2012-12-27 13:19) [18]

5) как вообще обмениваться данными между сервером и приложением. тут ведь не просто строку надо передавать. тут более сложные механизмы

Ага.
Я даже слышал когда-то, что для сервера приходится писать какие-то слова. Причем не на русском, а на каком-то собачьем языке "ЭсКьюЭль"

← →
tesseract © (2012-12-27 13:19) [19]

> + как грамотно реализовать автоматический апдейт клиентского
> приложения

Вывести всю логику в DLL, главное приложение при подключении запускает DLL с обновлениями, проверят хэши файлов, подгружает новые и в случае успеха запускает главную DLL на выполнение.

← →
MsGuns © (2012-12-27 13:20) [20]

>DevilDevil © (27.12.12 12:29) [4]
>ну там сканы документов всяких. А в чём хранить то, в BLOB-ах ?

О, вычитал по третьему разу :)
Ну, это уже кое-что. Искать про "автоматизация документооборота". И ни в коем случае не пытаться сделать самостоятельно ибо не получится ничего путного. Гарантирую :)

← →
Медвежонок Пятачок © (2012-12-27 13:21) [21]

ибо не получится ничего путного.

А должно?
:)

← →
Медвежонок Пятачок © (2012-12-27 13:24) [22]

PS
Обычно получается нечто, что даже на первый взгляд работает.
Но рядом должен сидеть автор, без своей поделки, но вооруженный management console.
И никуда не отходить. Иначе .....

← →
MsGuns © (2012-12-27 13:27) [23]

>Медвежонок Пятачок © (27.12.12 13:21) [21]
>А должно?

Смех смехом, но не ИМХО это одна из самых капризных задачек. Я не только сам пытался делать что-то подобное самостоятельно или в команде, но и внедрял готовых монстров. Результат всегда был много хуже, чем рассчитывало начальство. Ибо это самое начальство плохо (или совсем не) представляло себе КАК ЖЕ ОНО ДОЛЖНО БЫТЬ, ЧТОБЫ БЫЛО ВСЕМ ХОРОШО.
В результате, если система была сильно жесткая, то был визг и параллельное хождение "живых" документов, а если демократичная, то пользы от системы было еще меньше ибо достоверности было ноль целых хрен десятых.

← →
знайка (2012-12-27 13:30) [24]

отбили штурм...

← →
Медвежонок Пятачок © (2012-12-27 13:30) [25]

Ну все верно.
Автоматизация и внедрение электронных безбумажных технологий увеличивает расход бумаги примерно вдвое против случая когда технологии не были внедрены.

← →
Пользователь Интернета (2012-12-27 13:40) [26]

> DevilDevil © (27.12.12 12:14) [1]
>
> + как грамотно реализовать автоматический апдейт клиентского
> приложения

Платформа Eclipse RCP. Всё уже написано.

← →
vuk © (2012-12-27 13:43) [27]

to DevilDevil © (27.12.12 12:12) :

> 1) можно ли отделаться только базой данных. Мне сказали,
> что не правильно хранить файлы в БД
Храним (вплоть до сканированных документов), никто не помер. Единственное - документы имеют отношение к разным сущностям и под документы разных сущностей есть своя база. В принципе, в MSSQL можно смотреть в сторону опций FILESTREAM для varbinary(max)

> 2) какие компоненты и библиотеки нужно использовать для
> работы с MS SQL Server
У нас используется SDAC. На мой взгляд, это лучше ADO.

> 3) каким образом принято разграничивать права пользователей

У нас реализована своя подсистема безопасности, со своими правами, привелегиями и тыды.

> 2) каким образом организовать систему входа (логин/пароль)
> и определять права пользователей

При использовании integrated security для MSSQL никакой дополнительеный "вход" не нужен, польхователь определяется автоматически. Права, по крайней мере в нашей системе, могут проверяться в разных местах, и на сервере и на клиенте, в зависимости от контекста.

← →
DVM © (2012-12-27 13:43) [28]

> tesseract © (27.12.12 13:16) [17]

> А файловая система - такая же база данных.

И спрашивается, на кой нам в программе две базы вместо одной

> vuk © (27.12.12 13:43) [27]

спасибо

> MsGuns © (27.12.12 13:27) [23]
> Пользователь Интернета (27.12.12 13:40) [26]

Вы, господа, куда-то не туда ушли.

----------------------------------------------------

ok. у меня остаётся два вопроса.

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

2) не могли бы вы посоветовать статейку, в которой доступным образом будут описаны зарекомендовавшие себя подходы в проектировании БД. Ну там в каких случаях нужно создавать справочники, как увязывать между собой сущности и т.д.

> [28] DVM © (27.12.12 13:43)
> И спрашивается, на кой нам в программе две базы вместо одной

Одна для проверяющих, вторя для себя.:)

*Сори. не "Пользователь Интернета", а "Медвежонок Пятачок"

> не могли бы вы посоветовать статейку

Статейку, блин. Это целая теория РСУБД. Да и срачей по подходам к проектированию и нормализации БД можно развить over 9000.
Метод проб и ошибок, не иначе.

> Существуют ли какие-то простые средства кэширования данных
> на клиентской стороне,

TClientDataSet
стандартный и удобный. Очень богатый.

> Статейку, блин. Это целая теория РСУБД. Да и срачей по подходам
> к проектированию и нормализации БД можно развить over 9000.
>
> Метод проб и ошибок, не иначе.

есть такая поговорка
"не нужно делать сложно там, где нужно делать просто"

очень хорошо подходит в данном случае. тем не менее с высоты прожитых лет можно вывести несколько простых правил и методик проектирования БД. они то мне и нужны. совсем не хочется методом проб и ошибок делать какашку )

> очень хорошо подходит в данном случае. тем не менее с высоты
> прожитых лет можно вывести несколько простых правил и методик
> проектирования БД. они то мне и нужны. совсем не хочется
> методом проб и ошибок делать какашку )

Гугли "Нормализация БД" или "Нормальные формы в БД"

> Существуют ли какие-то простые средства кэширования данных
> на клиентской стороне, чтобы не дёргать постоянно удалённый
> сервер с передачей данных

Любой веб-браузер с тем или иным успехом справляется с задачей кеширования.
С учетом не гарантированности наличия устойчивого ШПД клиента в сеть сервера, а так же перспектив частых обновлений прикладных частей софта, есть прямой резон обратить взор в сторону распределенного 3-хзвенного к/с веб-приложения : браузер (тонкий веб-клиент) + веб-сервер (со встроенным или отдельным сервером приложений) + СУБД-сервер

> DevilDevil © (27.12.12 12:12)
> Здравствуйте уважаемые форумчане
...

Не заметил в исходных требованиях:
- Все пользователи в одной локальной сети или как?
- Все пользователи живые люди или как?
- Что за файлы и зачем надо хранить?

> 1) можно ли отделаться только базой данных. Мне сказали,
> что не правильно хранить файлы в БД

Полностью зависит от задачи. Но клиентское приложение таки придется писать.

> 3) каким образом принято разграничивать права пользователей
А как надо разграничивать? Тут, собственно ответ и кроется только средствами сервера или писать свое.
Если только средствами сервера то не получится легко и просто:
- не отображать в клиентском приложении недоступные пункты меню, формы, кнопки и т.п.
- разделить доступ к данным "по горизонтали" (запись 1 доступна только Васе а запись 2 и Васе и Пете ...)
Например в целях разграничения прав существует следующий подход
Прямой запрос к таблицам и представлениям запрещен, весь вынос данных только через хранимые процедуры
В "каждой процедуре" первой строчкой функция дающая ответ имеет ли пользователь право выполнить эту процедуру с этими входными данными
Спорный подход, но таки работает и почти не кашляет. Естественно в ущерб быстродействию но в + к "разграничению доступа"

> 2) каким образом организовать систему входа (логин/пароль)
> и определять права пользователей

Исходя из того, что куплен мелкософт - доменная аутентификация вполне подойдет. Права - какие такие права? (сначала определится что от прав надо)

> 3) как реагировать на разрыв связи и прочие неполадки с
> коннектом, как отлавливать
А как надо? В принципе нет коннекта к БиДе - нет работы. Но тем не менее если есть непокобелимые требования - танйцы с бубном вокруг локальныъ БиДе, кеширования в них и последующей синхронизации данных могут спасти. Но стоит ли овчинка выделки?

> 4) как организовать передачу файлов

ЗАЧЕМ? Почему передача файлов? Это что, база данных или торрент трекер?

> Ну и потом по БД интересна информация. В каких случаях нужно
> создавать справочники, как увязывать между собой сущности
> и т.д.
Читать Дейта, разбиратся с моделью Сущностей-Связей и т.д.

> честно говоря нет желания сейчас программировать под браузеры

Броузер - это всего лишь вариант реализации клиентской части приложения.

Мозговой штурм на тему разработки клиент-серверного приложения Найти похожие ветки