Книга по клиент - серверным БД.

← →
kilonet © (2006-04-12 18:44) [0]

Товарищи-прграммисты, нужна вот такая книга.
Что хотелось бы в ней прочитать: КАК и КОГДА надо использовать триггеры, сохранённые процедуры, различные типы курсоров, блокировок и т. д. Интересует практика создания и проектирования клиент-серверного ПО.
Книга может быть про БД вообще или по кокретной СУБД.
Что посоветуете?

← →
Sergey Masloff (2006-04-12 20:29) [1]

Дейта прочел уже? Если нет то большинство остальных читать пустая трата времени будет. Естественно в нем нет ни слова о дельфи и тому подобному.
Для начинающих и с дельфи у Ч. Калверта и М.Кенту есть что почитать на эту тему но... Я бы все же советовал с дейта начать.

← →
kilonet © (2006-04-12 21:07) [2]

вобщем-то я и в БД и в Delphi не новичёк.

Очень понравилась книга Кэнту "Delphi 7 для профессионалов" и, в частности, материал про БД. Хотелось бы побольше и поосновательней. И не обязательно в привязке к Delphi.

Тысечестраничные талмуды, наподобие Дейта я уже читал.

← →
Sergey Masloff (2006-04-12 21:14) [3]

kilonet © (12.04.06 21:07) [2]
Видимо, смотрел в книгу а видел... Хотя это только мое предположение и на истину не претендую. Лично у меня чтение Кэнту по вопросам работы с СУБД производило впечетление детского лепета. Хотя вобщем-то к автору этому очень неплохо отношусь.
Впрочем, у каждого свой выбор. Мое дело посоветовать ;-))

← →
Sergey Masloff (2006-04-12 21:20) [4]

Кстати вышла новая книжка Кайта как раз вроде по проектированию систем. Еще в глаза не видел может подойдет?

← →
Anatoly Podgoretsky © (2006-04-12 21:24) [5]

kilonet © (12.04.06 21:07) [2]
Если прочитал Дейта, то уже более ничего читать не надо, смеяться будешь.

← →
Игорь Шевченко © (2006-04-12 21:52) [6]

> КАК и КОГДА надо использовать триггеры, сохранённые процедуры,
> различные типы курсоров, блокировок и т. д.

А что, по подобным методикам книжки есть ? Вне зависимости от конкретной СУБД ?
Странно.
На мой взгляд (уж извиняюсь) такие книжки, если есть, то похожи на то, какие кнопки есть в среде разработки, например, в Delphi, и КАК и КОГДА их надо кидать на форму.
Лучше что-нибудь общее по базам читать, например Мартина или Ульмана, потом вопросы о том, как и когда, можно будет прочитать в документации к конкретной СУБД или в ее популярном изложении, например, как Том Кайт излагает про Oracle.

← →
Sergey Masloff (2006-04-12 22:05) [7]

Игорь Шевченко © (12.04.06 21:52) [6]
Ну Мартина то сейчас фиг достанешь. Или ты не о "Организация баз данных в вычислительных системах" 77 года которую Мир в 1980 переведенную издавала?

← →
kilonet © (2006-04-12 22:28) [8]

приведу примеры, вопросов которые у меня возникают:
1. Слышал, что безопасное изменение данных должно происходить через сохранённые процедуры. Как их надо использовать в таком случае и когда можно без них обойтись?

2.Провервка введённых данных должна осуществлятся на клиенте, или на сервере, или и там и там?

3.как часто надо обновлять данные на сервере: при любом изменении или накопив определённый их объем?

и т. д...

Вопрос не в ответах на эти конкретные вопросы. Где получить на них (и не только) ответы? Или это возможно только путём набивания шишек в конкркетных условиях.

← →
Игорь Шевченко © (2006-04-12 22:45) [9]

Sergey Masloff (12.04.06 22:05) [7]

> Ну Мартина то сейчас фиг достанешь.

Я как-то достал :)

kilonet © (12.04.06 22:28) [8]

> 1. Слышал, что безопасное изменение данных должно происходить
> через сохранённые процедуры

Что подразумевается под "безопасным изменением" ?

> Как их надо использовать в таком случае и когда можно без
> них обойтись?

Зависит от конкретной СУБД.

> 2.Провервка введённых данных должна осуществлятся на клиенте,
> или на сервере, или и там и там?

Куда введенных ? На сервере должна осуществляться проверка, которая гарантирует целостность и логическую непротиворечивость данных, например, CHECK CONSTRAINTS, PRIMARY/FOREIGN KEYS, логические взаимозависимости между данными в одной или в разных таблицах (пересчет итогов в главной таблице при вставке/удалении записей подчиненной таблицы - один из любимых примеров в книжках по использованию СУБД).

> 3.как часто надо обновлять данные на сервере: при любом
> изменении или накопив определённый их объем?

Не имеет значения.

← →
Sergey Masloff (2006-04-12 22:46) [10]

kilonet © (12.04.06 22:28) [8]
В книгах про это не прочтешь... Столько всяких факторов. Только опыт и конкретная задача. Универсального рецепта нет.
Например -
1) В чем безопасность-то? И чем технически View обложеный триггерами опаснее? Например.

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

← →
kilonet © (2006-04-12 23:03) [11]

да похоже увы...

блин..., что же делать?

← →
Sergey Masloff (2006-04-12 23:05) [12]

kilonet © (12.04.06 23:03) [11]
А кому сейчас легко? Не огорчайся и дерзай все получится (не с первого раза - гарантирую)

← →
Sergey Masloff (2006-04-13 20:20) [13]

kilonet © (12.04.06 23:03) [11]
Я понял что тебе нужно! ;-)
С. Санблед, П.Санблед Разработка масштабируемых приложений для Windows. Ориентирована на MSSQL + Visual Basic, сейчас наверняка есть и для бейсика дотнет. Как раз у ребят довольно проработаная система относительно и проверок и размещения логики и хранимых процедур и другого. Лично у меня есть претензии к их методе ;-) но познакомиться вобщем-то интересно. Это шведы толи братья толи папа и сын но они реальные разработчики а не просто писатели, у них точно есть промышленные реализации по их методике. К тому же в MSDN немало их статей то есть по любому ребята серьезные.
Читай пользуйся вспоминай меня добрым словом ;-))

ISBN 5-7502-0153-8

← →
Суслик © (2006-04-13 21:38) [14]

2Автор

Мое имхо.
Все зависит от задачи и от навыков людей.

У нас корректность на уровне корректности ссылок и уникальности "держится" на сервере (mssql).

Логика, держится на клиенте, при том, что инструменты блокировок сервер клиенту предоставляет.

Но! Думаю, что аналогичная нашей архитектура возможна только если ты в состоянии в рамках одного приложения клиента написать четко 2 уровня - GUI и логика. У меня это как-то получилось (времени было много да и желания). Сейчас бы я за такое не взялся.

Если развивать мое имхо, то скажу, что уверен, что однозначного ответа на твой вопрос нет. Нужна задача + ее решение (успешное есно). Только таким образом можно сформировать понимание того что и как надо делать. Конечно при этом нужно базовое знание теории. Но такое знанине, как ты сказал, ты уже получил.

← →
Суслик © (2006-04-13 21:43) [15]

2Автор (еще немного).

А зачем зацикливаться на клиент-сервере? Есть трехуровневые архитектуры. Тот же j2ee. Там БД вообще отходят на второй план. Все сосредоточнение идет на логике. Сериализация в БД зачатую делается посредством библиотек меппинга (hybernate для java).

У такой атрхитектуры есть определенные и немалые преимущества - например, масштабируемость постредством распределения нагрузки на источник данных. В К-С арх. ты такого не сделаешь никак (вполне возможно, что это уже есть в промышленных СУБД, но к теме "теории" БД это уже отношения не имеет - это уже вопрос конкретного продукта и технологий).

← →
Sergey Masloff (2006-04-13 21:49) [16]

Суслик © (13.04.06 21:43) [15]
>Там БД вообще отходят на второй план.
Призрачное это масштабирование. Когда с промышленными СУБД как д дбф-ом начинают работать. Конечно производителям железок выгодно. А используя на полную катушку средства СУБД можно на одной железке спокойно держать нагрузку как на десятимашинном кластере каждое плечо которого стоит дороже чем твоя единичная железяка ;-)
Впрочем рискуем вступить в ненужный холивор ;-)))

← →
Суслик © (2006-04-13 21:55) [17]

> Впрочем рискуем вступить в ненужный холивор ;-)))

Это точно.
Я бы только хотел добавить, что иногда тяжесть, но востребованность, задачи такова, что приходится идти на жертвы в лице производительности.

Например, у нас сейчас решается задача параллельного ведения учета по МСФО (международный стандарт) + РСБУ (российский стандрарт) + НУ (налоговый учет). Не знаю, насколько ты близок к бухгалтерии, но уверяю, что данная задача очень сейчас востребована. Настолько востребована, что лучше ее сделать с медленным сервером, чем не сделать с быстрым.

← →
Суслик © (2006-04-13 21:57) [18]

Еще.

И потом, не все решают задачи с десятками или сотнями млн. сущностей. Есть много задач (та же бух-ия), где сущностей намного меньше, но вот гибкость решения востребована очень сильно, а гибкость все-таки (не хотел бы спорить) в ООП средах достигается легче, чем в языках типа T-SQL (другого не знаю).

← →
Sergey Masloff (2006-04-13 22:02) [19]

Суслик © (13.04.06 21:55) [17]
>Не знаю, насколько ты близок к бухгалтерии
Страшно далек... ну там дебет от кредита отличу и что такое план счетов знаю не больше. Поэтому на эту тему мнения своего иметь не могу.

А задачи и правда разные бывают кто ж спорит

← →
Суслик © (2006-04-13 22:05) [20]

offtop
Ты мне вот скажи - почему у твоей программы логотипа нет - штатный от дельфи?

← →
Sergey Masloff (2006-04-13 22:08) [21]

Суслик © (13.04.06 22:05) [20]
1) У какой из них?
2) А на фига...
или вопрос не мне? ;-)))

← →
Суслик © (2006-04-13 22:12) [22]

Тебе, той которая стоит в офисах продаж :)
Такая система серьезная - столько полей ввода - жуть. А логотип от дельфи :)

ЗЫ. Извините за оффтоп.

← →
Суслик © (2006-04-13 22:13) [23]

2Сергей Маслов.
Ты вот, кстати расскажи, какая у нее архитектура.
Чессо слово страшно интересно. Да и автору полезен практических опыт будет.

← →
Sergey Masloff (2006-04-13 22:26) [24]

Суслик © (13.04.06 22:13) [23]
Ну ты сказал моя... Я винтик хоть и не самый маленький ;-)))
А так - все на сервере. На клиенте только презентация (ну и проверка ввода но она с сервера управляется).
Что позволяет иметь на данный момент несколько клиентов ("толстый", трехзвенный, веб и в виде веб-сервисов) использующих одну и ту же логику. Трехзвенка - просто трубка к серверным процедурам (ну правда еще шифрование и сжатие).

← →
Суслик © (2006-04-13 22:31) [25]

> ну и проверка ввода но она с сервера управляется

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

Сервер? Oracle?

← →
Суслик © (2006-04-13 22:32) [26]

А вот! Как сделан коннект от офиса до сервера (или их несколько): через vpn или просто через internet?

← →
Суслик © (2006-04-13 22:38) [27]

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

Т.е. иначе говоря - это проверки задаются декларативно или императивно?

← →
Sergey Masloff (2006-04-13 22:38) [28]

Суслик © (13.04.06 22:32) [26]
>Как сделан коннект
И так и сяк. Серверов(приложений - как я сказал это просто трубки) много. Кто работает по VPN тот просто работает. Кто работает просто через инет - у них аппаратные ключи.

сервер - оракл это не секрет.

>Некое подобие схемы метаданных
Нет все проще... если упрощенно то просто строка которая говорит какому контролу что делать - видимый там он или только чтение или допускает ввод только из справочника. Строка парсится и контролы принимают нужный вид. Клиент вобщем-то не обязан это анализировать сервер все равно потом проверяет как будто клиент ничего не знает. Просто это снижает частоту отлупов.

> Нет все проще... если упрощенно то просто строка которая
> говорит какому контролу что делать - видимый там он или
> только чтение или допускает ввод только из справочника.
> Строка парсится и контролы принимают нужный вид. Клиент
> вобщем-то не обязан это анализировать сервер все равно потом
> проверяет как будто клиент ничего не знает. Просто это снижает
> частоту отлупов.
> <Цитата>

Это голубейшая мечта нашего стрШого по sql серверу :)
А у вас взаимосвязи полей есть? Ну типа - ввел одно поле, 30 других пересчитались? Если есть, то как вы это делаете?

> Кто работает просто через инет - у них аппаратные ключи.

Если ты не против, то спрошу тебя потом приватно про это подробней :)
Ну или здесь расскажи.

← →
Sergey Masloff (2006-04-13 22:48) [30]

Суслик © (13.04.06 22:42) [29]
Тут не расскажу про ключи. По почте - можно.

>А у вас взаимосвязи полей есть?
Есть но на клиенте ничего не считается. Просто по подтверждению значения такого поля все уходит на сервер пересчитывается и возвращается пересчитаным. Конечно из за-этого лишние обмены но...

> Например, у нас сейчас решается задача параллельного ведения
> учета по МСФО (международный стандарт) + РСБУ (российский
> стандрарт) + НУ (налоговый учет).

Я тоже знаю много страшных слов. Но какой отношение количество звеньев и прочие там клиент-серверы имеют к МСФО+РСБУ+НУ+НА ?

> Конечно из за-этого лишние обмены но...

это копейки.

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

Если п. 1, то как у вас сделана отмена ввода. Например, агент начал править полис, но передумал (мало ли).

> Игорь Шевченко © (13.04.06 22:55) [31]

Вопрос в твоем стиле. Позволь на него не отвечать в полном объеме.
Скажу только то, что каждый работает как умеет и сознательно жертвует чем-то (иначе имхо не бывает). Мы жертсвуем производительностью в угоду результату - ну не умеем мы иначе, нет в природе таких консультантов в предметной области БУ, которые поставят задачу в виде пригодном для фундаментального высокопроизводительного решения.

:)

← →
Некто_ (2006-04-13 23:08) [34]

Суслик © (13.04.06 23:03) [33]

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

> Игорь Шевченко © (13.04.06 23:08) [35]

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

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

Суслик © (13.04.06 23:13) [36]

Абсолютно не обидел, даже и не думай. Я, например, могу привести кучу терминов из своей предметной области, но они никаким образом не подскажут тебе о том, какой из способов взаимодействия с СУБД мне можно предложить и какой из способов наиболее вероятно я использую. Об чем, собственно, и спросил :)

2ИШ
Ты все же прочти [36]. Понимаешь, мы не умеем делать хорошую архитектуру и делать нужное дело. Рефакторинг нас спасет (и спасает).
Вот в этом и связь - сделать быстро и "плохо" (а плохо ли?), потом переписать. :)

Суслик © (13.04.06 23:13) [36]

А что касается консультантов, то они тоже всякие бывают. Может вам "экземпляр неудачный" попался ?

Книга по клиент - серверным БД. Найти похожие ветки