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

← →
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]

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

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

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

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

спасибо

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

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

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

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

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

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

← →
Inovet © (2012-12-27 14:40) [30]

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

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

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

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

← →
Ega23 © (2012-12-27 14:43) [32]

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

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

← →
O'ShinW © (2012-12-27 14:45) [33]

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

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

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

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

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

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

← →
Ega23 © (2012-12-27 14:50) [35]

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

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

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

> Ega23 © (27.12.12 14:50) [35]

спасибо

← →
Сергей М. © (2012-12-27 15:02) [37]

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

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

← →
DevilDevil © (2012-12-27 15:06) [38]

> Сергей М. © (27.12.12 15:02) [37]

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

← →
Павел Калугин © (2012-12-27 15:26) [39]

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

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

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

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

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

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

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

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

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

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

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

← →
Павел Калугин © (2012-12-27 15:27) [40]

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

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

← →
Сергей М. © (2012-12-27 15:37) [41]

> DevilDevil © (27.12.12 15:06) [38]
> честно говоря нет желания сейчас программировать под браузеры

А ты все же попробуй - потом за уши не оттянешь)

← →
DVM © (2012-12-27 15:58) [42]

> Павел Калугин © (27.12.12 15:26) [39]

> В "каждой процедуре" первой строчкой функция дающая ответ
> имеет ли пользователь право выполнить эту процедуру с этими
> входными данными
> Спорный подход, но таки работает и почти не кашляет. Естественно
> в ущерб быстродействию но в + к "разграничению доступа"

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

← →
MonoLife © (2012-12-27 16:12) [43]

> обратить взор в сторону распределенного 3-хзвенного к/с
> веб-приложения : браузер (тонкий веб-клиент) + веб-сервер
> (со встроенным или отдельным сервером приложений) + СУБД-
> сервер

я в свое время попробовал на php написать это дело, внутри организации документооборот, понравилось
> за уши не оттянешь)
:)

← →
vuk © (2012-12-27 16:24) [44]

to DVM © (27.12.12 15:58) [42]:

> Если разграничивать доступ не персонально по пользователям,
> а по группам, и иметь не более 64 групп

А потом внезапно случается необходимость либо первого, либо второго - и привет. :) Могу сказать, что у нас используется, в основном, управление на уровне групп, но разрешения для групп автоматически раскрываются в пользовательские.

← →
знайка (2012-12-27 16:39) [45]

> Броузер - это всего лишь вариант реализации клиентской части
> приложения
так уж прям и всего лишь.. есть и нехилая разница. И опять таки html определяет ГУИ или нет.

← →
Jeer © (2012-12-27 16:44) [46]

Начать с уже изобретенных "велосипедов" для создания АИС:

Datarun, CMM, Rational Software, Microsoft Solution Framework (MSF), Rational Unified Process (RUP), Oracle Method, SADT (IDEFx).

P.S.
И забыть об ассемблере:)

← →
Сергей М. © (2012-12-27 16:46) [47]

> знайка (27.12.12 16:39) [45]

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

← →
Jeer © (2012-12-27 16:52) [48]

> А ты все же попробуй - потом за уши не оттянешь)

Тем временем фрейворк raudus от Клопова уже доставляет приличное наслаждение.
Реализовал пару-тройку проектов для Интранет - клиент тащится:)
Добавил выход на мобильные девайсы - народ выпал в осадок.

← →
Сергей М. © (2012-12-27 17:03) [49]

> Jeer © (27.12.12 16:52) [48]

Я пока не решаюсь сделать на него ставку.

Да и вот это

This release starts a new branch.
Release 0.9.0 contains only RaVCL controls

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

Еще там напрягает отсутствие слоя, дающего хоть какой-то доступ к формированию и передаче браузеру пользовательского JS-кода.

← →
Сергей М. © (2012-12-27 17:38) [50]

Еще вот это напрягает:

Posted on 20.10.2012 by igorklopov
Raudus 0.9.2 is released.
..
2) New RaVCL control: TRaDBGrid. It has reduced functionality yet – cells are not editable, columns are not resizable. But rich UI for the grid is planned

дбгрид - настолько распространенная и нужная петрушка в веб-приложениях, что рожать его нужно бы первоочереднее и пошустрее, благо ExtJs обладает предостаточными возможностями для этого ..
На дворе 2013 год, однако, а дбгрид у Раудуса до сих пор имеет "жалкий вид и макаронную походку" - кому он нафих нужен без редактирования,ресайза и многих других вкусностей и полезностей ?)

← →
Jeer © (2012-12-27 18:18) [51]

> кому он нафих нужен без редактирования,ресайза

Мне проще - практически никогда не применял какой-либо грид в качестве инструмента редактирирования. Можно считать бзиком:)

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

всем участникам дискуссии спасибо!
информации достаточно

← →
знайка (2012-12-27 19:54) [53]

> Сергей М. © (27.12.12 16:46) [47]
я и не говорю про возможности, с ними все как раз в порядке. ;)
Я про то, что - как делать клиента, влияет и на серверную сторону.
Одно дело это какие-нить веб-сервисы (отдающие, к примеру, джсон ну и там сессии поддержать), и совсем другое веб-приложение со всеми рюшечками.

← →
Пит (2012-12-27 23:01) [54]

> практически никогда не применял какой-либо грид в качестве
> инструмента редактирирования. Можно считать бзиком:)

почему бзик. Абсолютно оправданный подход.

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

Единственный в мире грид, который я видел и который подходит для редактирования данных - это excel.

← →
Пит (2012-12-27 23:08) [55]

> Читать Дейта, разбиратся с моделью Сущностей-Связей и т.
> д.

читать дейта как введение в БД? Гы гы... не бережете вы новичков! Нет лучшей книги, чтобы почувствовать себя никчемным идиотом, а слово кортеж возненавидеть на всю жизнь.

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

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

> Убью любого, который начнет использовать грид для редактирования
Начинайте с микрософта.

← →
vuk © (2012-12-27 23:41) [57]

to Пит (27.12.12 23:01) [54]:

> Убью любого, который начнет использовать грид для редактирования

Руки коротки! :P Гриды для редактирования используем лет 10, никаких проблем в этом нет.

> это жутко неудобно для пользователя.

Тут все зависит от реализации и от методики взаимодействия с серверной частью.

> Где начало редактирования, где окончание - хрен разберешь.

Зависит от того, что понимается под понятием "редактирование". Где конец редактирования у одного поля БД - вполне понятно.

> Вставка новой записи - это уже на грани фола по интуитивности
> интерфейса.

Вот вставка в гриде - это да, неинтуитивно. У нас не используется.

> Прибавляем фильтрацию данных - и полный конец обеда.

А какая нафиг разница для редактирования, есть фильтрация или нет?

← →
Jeer © (2012-12-27 23:57) [58]

> А какая нафиг разница для редактирования, есть фильтрация
> или нет?

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

← →
Пит (2012-12-28 00:01) [59]

> Гриды для редактирования используем лет 10, никаких проблем
> в этом нет.

ну знаешь, Алексей, иногда программистов послушаешь - действительно никаких проблем и нету. А поговоришь с пользователями - они волком воют.

> Зависит от того, что понимается под понятием "редактирование".

вот именно

> Где конец редактирования у одного поля БД - вполне понятно.

ты хотел сказать - у одного поля грида?
И где же?

Когда происходит комит в базу?
На каком этапе и как можно отменить редактирование? Каким образом можно подтвердить сохранение изменения?
Как дать команду на начало изменения данных?

> Вот вставка в гриде - это да, неинтуитивно

согласен

> А какая нафиг разница для редактирования, есть фильтрация
> или нет?

понятное дело, что если ты видишь запись в гриде - значит, она удовлетворяет условию фильтрации. Но вполне возможна ситуация, что изменив данные - оно перестанет удовлетворять условию фильтрации. И вот что тут делать - непонятно. Есть разные подходы к данному вопросу, но ни один из них не вызывает у меня восторга.

Конечно, данная проблема существует и в классической интерпретации аля "Журнал записей в виде грида + карточка записи в виде отдельной формы". Что делать с гридом после изменения записи в отдельной форме?

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

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

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

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

← →
vuk © (2012-12-28 00:48) [60]

to Пит (28.12.12 00:01) [59]

> ты хотел сказать - у одного поля грида?
> И где же?

Я немного неверно выразился. Имел в виде поля в DataSet - грид, он же не в вакууме, как правило, а к датасету подключен. А там по окончани редактирования OnChange срабатывает.

> Когда происходит комит в базу?

Вот у нас - ровно там и происходит. В OnChange.

> На каком этапе и как можно отменить редактирование? Каким образом можно подтвердить сохранение изменения?

Берем тот же cxGrid и начинаем редактировать. Для примера возьмем текстовое поле. Пока не нажали Enter находимся в режиме редактирования поля, если в это время нажать Esc, из редактирования выпадаем с восстановлением оригинального значения. Вот именно для этого не нужно делать ничего вообще.

> Как дать команду на начало изменения данных?

Что есть "команда на начало изменений"? DataSet переводится в состояние редактирования тем же гридом автоматически.

> Но вполне возможна ситуация, что изменив данные - оно перестанет
> удовлетворять условию фильтрации.

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

← →
Германн © (2012-12-28 01:31) [61]

> vuk © (27.12.12 23:41) [57]
>
> to Пит (27.12.12 23:01) [54]:
>
> > Убью любого, который начнет использовать грид для редактирования
>
> Руки коротки! :P Гриды для редактирования используем лет
> 10, никаких проблем в этом нет.
>

Я использую уже 16 лет с хвостиком. Первая программа, в которой используется редактирование в гриде впервые вышла в 1996. И продаётся и поддерживается (в т.ч. с выходом новых версий) до сих пор.
Но естественно редактирование в гриде в этом ПО используется не везде, а только там, где это удобно для пользователя и не опасно для БД.

← →
Сергей М. © (2012-12-28 10:09) [62]

> Пит (27.12.12 23:01) [54]

Это тебе просто посчастливилось не застать времена "расцвета" SuperCalc"а)

← →
sniknik © (2012-12-28 11:07) [63]

> А поговоришь с пользователями - они волком воют.
дело привычки... у меня "выли" при переходе с досовского фокса/редактирования в гриде на 1С с редактированием в формах. время ввода/проверки накладных с нескольких секунд (взять "на основании", пробежаться/поменять в гриде по "количествам", сравнить получившуюся сумму. добавление было как формой так и в гриде из списка товаров поставщика (в 1с-ном модуле такого тогда так не сделали)/вводом кода/артикула в гриде) до 10 - 15 мин... (с вводом системы взяли дополнительно 2х операторов, и если раньше один казалось "ничего не делал" то после все 3 были "сильно заняты").

> Это тебе просто посчастливилось не застать времена "расцвета" SuperCalc"а)
до сих пор фокс (старую систему) с ностальгией вспоминаю. а почитаешь сейчас "как надо" и понимаешь, тогда все было "не правильно", но блин УДОБНО.

← →
MsGuns © (2012-12-28 12:17) [64]

>Пит (28.12.12 00:01) [59]
>ну знаешь, Алексей, иногда программистов послушаешь - действительно >никаких проблем и нету. А поговоришь с пользователями - они волком воют.

Это потому что так криво реализовано. Редактирование в сетке незаменимо если требуется изменение большого кол-ва однотипных данных в сжатый отрезок времени, в т.ч. и похожих записей. Модальные окна с подсказками, варнингами и подтверждениями в данном случае просто неуместны.
Конечно, тупым бросанием и "мушечной" настройком компонент такое не реализуется (если какой-нибудь Архонов будет утверждать обратное - плюньте ему в лицо), надо ручками и головой поработать, это да !

>sniknik © (28.12.12 11:07) [63]
>до сих пор фокс (старую систему) с ностальгией вспоминаю. а почитаешь >сейчас "как надо" и понимаешь, тогда все было "не правильно", но блин >УДОБНО.

Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)

← →
знайка (2012-12-28 12:25) [65]

Откройте SQL Server Menagement Studio, и в ней добавить новую таблицу в базу. Все в гриде, и добавляется и редактируется.
И где там чего не понятно, и капец всему? Или там писали инопланетяне? :)

В Excel-е тоже вот сетка. И как-то редактируют в ней.

to MsGuns © (28.12.12 12:17) [64]:

> Тогда не было многопользовательсконо доступа, транзакций
> и много чего еще :)

Не, я понимаю, кнечно, что есть люди, которые на вопрос, "А почему не сделать редактирование прямо в гриде?" отвечают - "Кааааак?!!1111 Там же транзакцыйа!!!1111 =8[ ]" Но вот лично я между этими вещами связи нифига не улавливаю. :)

> [64] MsGuns © (28.12.12 12:17)
> Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)

Многоползователей было, транзакций не было.

>Но вот лично я между этими вещами связи нифига не улавливаю.

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

> Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)
что характерно в первых 1С тоже... но написано было "по правилам".

> Но вот лично я между этими вещами связи нифига не улавливаю. :)
+ 1

ну, не было, ну был файл сервер, и что?
насколько помню там каждая накладная это был отдельный файл, редактировал каждую один оператор (он и был один :), но теоретически могло быть сколько угодно, и накладную можно было вводить частями (перед приемкой "склеивало").
в таком стиле, хоть счас на клиент сервер переноси, никаких коллизий не будет. но методов подобных почему то нет (не распространены), а вот правил (как сделать неудобно и оправдаться, ИМХО) навалом.

> MsGuns © (28.12.12 14:01) [69]

А как там сейчас в 1С обстоят дела с транзакционными делами при использовании системы в файловом режиме ?

to MsGuns © (28.12.12 14:01) [69]:

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

Фигзнает. В VCL любой механизм редактирования набора данных сводится к DataSet.Edit -> ... -> DataSet.Post. При этом всё это нормально прехватывается и приводится к любому виду взаимодействия с БД, какой нужен.

>В VCL любой механизм редактирования набора данных сводится к DataSet.Edit -> ... -> DataSet.Post.

Нет, далеко не ЛЮБОЙ.

>При этом всё это нормально прехватывается и приводится к любому виду взаимодействия с БД, какой нужен

Нет, не все. Я уже рассказывал про BDE и TTable например. Если лично у Вас не было проблем с гридной технологией, то это не значит что их вообще не было.

> Нет, далеко не ЛЮБОЙ.

Приведи пример.

Для примера, напишите простое приложение на работу с таблицей в акцесе используя "нормально перехватывающий" TADOTable. Затем запустите два экземпляра этого приложения. И вы получите дупу.
С чего бы ? Ведь связей гридного редактирования с "транзакциями" "не видно"

>Приведи пример.

Append/Insert/AppendRecord/Delete,Refresh etc

> [69] MsGuns © (28.12.12 14:01)
> В результате имеем что если хочешь работать в локалках надежно,
> то забудь про гридное редактирование либо используй, но
> контролируя каждый клик, шмяк и чих юзера.

Да ладно. На FoxPro 2.6 в гриде
locate all for rlock() && найти и заблокировать первую незаблокированную запись browse fields ; field1 параметры, ; и т.д. прописываем какие и как отобраджать поля ; when rlock() valid funlock() ******************************** function funlock unlock return .t.

> Append/Insert/AppendRecord/Delete,Refresh etc

По-сути - одно и то же.

> знайка (28.12.12 12:25) [65]
> Откройте SQL Server Menagement Studio, и в ней добавить
> новую таблицу в базу. Все в гриде, и добавляется и редактируется.
>
> И где там чего не понятно, и капец всему? Или там писали
> инопланетяне? :)

пересадить всех бухгалтеров на нее

Ганс вроде прав :)

хоть ADOTable базируется на TCustomADODataSet, откуда ноги у всех растут, но
вводится режим TableDirect, что делает - не понятно, но не поддерживает события

например
procedure TCustomADODataSet.EnableEvents;
if (CommandType = cmdTableDirect)

then
DatabaseError(SEventsNotSupported);

← →
знайка (2012-12-28 14:41) [81]

> DVM © (28.12.12 14:38) [79]
У нас клиенты не бухгалтеры, но тоже им делаем в гриде, да и не то что мы это их требование. И что вы хотели сказать?

> Затем запустите два экземпляра этого приложения. И вы получите дупу.
только при удалении в одном и попытке редактирования этой же записи в другом... в фоксе для этого не было физического удаления, до ZAP-а.
а если удалять/редактировать в формах, ну по правилам, разве не тоже самое будет?

> Единственный в мире грид, который я видел и который подходит
> для редактирования данных - это excel.

Именно поэтому и тогда, когда нужны массовые закачки данных, непротиворечащих закачкам от других юзеров, отдаю юзерам спец.формы Excel, куды они молотят в гриде свои данные - потом программная верификация и массовая закачка.
Т.е. для таких случаев реализую технологию импорта.

← →
Аббат Пиккола (2012-12-28 15:56) [84]

Фигня это все.

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

Только нужно с умом организовать ряд вещей. Например, совершенно не к чему подтверждать транзакции после изменений в каждой строке.

У меня все многострочные документы редактируются в гриде.
Краеугольным является решение проблемы со ссылочным полем (например, товар в накладной). Я делаю традиционно так: пользователь набирает кусочки наименования прямо в поле сетки. Сетка имеет специальное событие (OnSetEditText), которое я добавил в этот компонент. Что позволяет на каждое нажатие клавиши осуществлять поиск в справочнике товаров. Под сеткой позиций документа во дополнительной сетке отображается результат SQL-запроса вроде этого:

SELECT ID, NAME FROM GOODS
WHERE UPPER(NAME) LIKE "%НА%" AND
UPPER(NAME) LIKE "%50%" AND
UPPER(NAME) LIKE "%BLUE%" AND

Запрос формируется на лету. В данном случае пользователь искал "Наволочка 50x50 Amazon Blue"

Как только он видит нужный объект в нижней сетке, он жмет дважды Enter. Первый раз это переводит фокус ввода в нижнюю сетку , потом стрелками он может выбрать из нижней сетки, если там к этому моменту больше 1 товара видно, затем он жмет Enter еще раз, фокус ввода возвращается в верхнюю сетку, наименование копируется туда. где он раньше набирал признаки поиска, параллельно ID товара копируется в датасет, а фокус ввода переводится на следующую ячейку (обычно это количество).
Скорость набора документа просто фантастическая. Добавление новой строки - просто стрелка вниз. В любой момент пользователь может нажать кнопку "сохранить", что вызывает Commit. Все, кто использовал этот интерфейс, ни на что другое смотреть потом не хочет. Именно из-за колоссальной скорости набора данных.

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

← →
Аббат Пиккола (2012-12-28 16:05) [85]

Для организации полей "сумма" используется событие DataChange датасоурса. В этом событии если переданный параметр Field

if (Field = <поле кол-ва>) or (Field = <поле цены>) then
<поле суммы> := <произведение цены на кол-во>;

Здесь могут быть и более сложные обработки. Это еще до отсылки на сервер все вычисляется. Иногда даже поверх вычисляемых сервером полей. Чтобы еще до отсылки видеть результат прямо в редактируемой строке.

На мой взгляд главное в этих делах - скорость и удобство для пользователя.

> Для организации полей "сумма" используется событие DataChange
> датасоурса. В этом событии если переданный параметр Field

На TDataLink завяжись.

> DevilDevil © (27.12.12 12:52) [9]
> и не скажется ли это на производительности БД, если хранить
> в ней файлы

А не скажется ли это на производительности БД, если хранить извне, тоже про целостность и прочее.

to MsGuns © (28.12.12 14:22) [75]:

> Для примера, напишите простое приложение на работу с таблицей
> в акцесе используя "нормально перехватывающий" TADOTable.
>

Это имеет отношение скорее к функционированию компонентов типа TTable (которыми я, кстати, завязал пользоваться лет 15 назад) вообще и соответствующего провайдера, а вовсе не к редактированию "через грид".

>имеет отношение скорее к функционированию компонентов типа TTable

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

Об чем собсна и был пост.

> Если разграничивать доступ не персонально по пользователям,
> а по группам, и иметь не более 64 групп, то разграничение
> прав даже на отдельных записях делается очень легко и совсем
> без снижения быстродействия при выборке. Просто каждой записи
> ставится в соответствие некоторое 64 бит число, каждый бит
> в котором означает доступ той или иной группе. Два таких
> числа дают возможность проверять доступ на чтение и запись.
> Маска группы передается в каждую хранимую процедуру делающую
> запрос, бинарными операциями (которые есть почти в каждой
> субд) можно отобрать подходящие под маску записи. Способ
> почти не снижает быстродействие.

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

to MsGuns © (29.12.12 12:04) [89]:

> Это имеет отношение к весьма популярной технологии проектирования
> "базовых" приложений по принципу "тяни-бросай", где грид
> играет основополагающую роль посредника между "базой" и
> "юзером".

Ну мы тут вроде не на уровне "Delphi для чайников" рассуждаем. Или не? :))

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