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

← →
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 тот просто работает. Кто работает просто через инет - у них аппаратные ключи.

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

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

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

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

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

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

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

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

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

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

← →
Игорь Шевченко © (2006-04-13 22:55) [31]

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

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

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

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

это копейки.

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

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

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

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

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

:)

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

> kilonet © (12.04.06 18:44)

Всё понял по "Мир InterBase" Ковязина и Вострикова.

← →
Игорь Шевченко © (2006-04-13 23:08) [35]

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

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

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

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

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

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

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

← →
Игорь Шевченко © (2006-04-13 23:17) [38]

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

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

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

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

← →
Игорь Шевченко © (2006-04-13 23:23) [40]

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

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

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

> Может вам "экземпляр неудачный" попался ?

Мы в этом проекте участие хвала аллаху не принимали :)

← →
Игорь Шевченко © (2006-04-13 23:39) [42]

Суслик © (13.04.06 23:20) [39]

Мы все-таки о разном. Я о том, что суть предметной области не может однозначно диктовать способ взаимодействия с СУБД, количество звеньев, и т.д. Ты же понимаешь, что одну и ту же задачу предметной области можно решить правильно разными путями. Способ взаимодействия определяет масштабируемость, не более того. Грубо говоря, если у тебя один пользователь вводит 1000 записей в день, или 1000 пользователей вводят каждый по 1000 в день, то здесь и надо искать различие, но задача-то при этом с точки зрения предметной же области, останется все той же - РСФО, ЗБСУ НУ и прочие страшние слова.

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

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

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

← →
Игорь Шевченко © (2006-04-13 23:57) [44]

Суслик © (13.04.06 23:44) [43]

> я не могу даже теоретически представить кто виноват

А представить, что делать или едят ли курицу руками, ты можешь ? :)
(Это три извечных вопроса, если что - кто виноват, что делать и едят ли курицу руками).

Вот возьми того же Фаулера, как ты полагаешь, он обладает самыми углубленными познаниями во всех предметных областях, с которыми ему приходилось сталкиваться, или все-таки достаточно знать набор шаблонов (или паттернов, как сейчас модно говорить) и уметь раскладывать большую проблему на ряд маленьких с известными решениями и есть слона по кусочкам ?

← →
Суслик © (2006-04-14 00:06) [45]

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

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

Поэтому в Фаулером сравнение считаю некорретным. Его успех основан на знании предметной области. Не зная ее хорошо невозможно сделать систему. В этом я уверен. Конечно, можно сказать, что можно написать такую систему, которая бы легко адаптировалась к задаче. Но это можно сделать в рамках разумного. Иначе ты напишешь R3, Скалу или BAAN (крупные erp системы), которые могу все - но это реальные монстры.

← →
Игорь Шевченко © (2006-04-14 00:29) [46]

Суслик © (14.04.06 00:06) [45]

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

← →
Суслик © (2006-04-14 00:31) [47]

> Игорь Шевченко © (14.04.06 00:29) [46]

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

← →
Игорь Шевченко © (2006-04-14 00:44) [48]

Суслик © (14.04.06 00:31) [47]

Это я все понимаю, но на подобные вещи вроде юристы существуют, законы толковать. Бухгалтера-то как-то умудряются работать, и вроде у них даже получается. Значит, они для себя алгоритм находят, верно ? А раз находят, то наверняка в том же тырнете делятся :)

← →
Суслик © (2006-04-14 00:59) [49]

> Игорь Шевченко © (14.04.06 00:44) [48]

Правильно излагаешь.
Но! Вот представь, если некий закон. Некие трактовки неоднозначны. На это существуют "толкования" разных уважаемых людей. Эти люди не министр финансов, не министр налогов и сборов, не дипутаты, принявшие закон. Это просто очень уважаемые люди (если не ошибаюсь есть такая фамилия Шеремет). То что они пишут это их личное мнение. На него можно полагаться, наверное, а может нельзя. Сделаешь как они пишут, придут к заказчику из органов, возмут за ж, с тебя спросят, а ты им - ну типа так писали "токователи". Какие такие писатели - закон видишь, вот тут написано, что этого делать нельзя (а это и не написано, а только подразумевалось под витьеватостью фраз).

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

← →
Sergey Masloff (2006-04-14 06:29) [50]

Суслик © (13.04.06 22:59) [32]
Я уже проснулся ;-)))

>Тогда вот что скажи (если можно). Архитектура:
>1. На клиент в какое-то поле произошел ввод
>2. Ввод отправился на сервер
...
>1. Сразу кидаете в таблицы?
>2. Или храните в спец. таблицах и кидаете в таблицы после подтверждения >ввода документа?

>Если п. 1, то как у вас сделана отмена ввода. Например, агент начал >править полис, но передумал (мало ли).
Два вида
1) При пересчете никакие данные в базе не меняются. Клиенту присто приходит курсор с интересующими его данными.
2) Твой пример с полисом неудачен. Полис или еще не был оплачен - тогда прямо сразу все меняется в таблицах и у клиента на экране актуальная серверная информация. Или его состояние было зафиксировано (он выпущен) и больше не меняется. При возникновении новых данных старые не удаляются никогда - только записываются новые так что это не проблема. Вообще на эту тему книжку можно написать но вот тебе ОЧЕНЬ примитивный пример.

Вот пришел страховать машину. Водители ты и жена у жены нет стажа. За это тариф выше. Ты оплатил полис и возникло условие -
Полис №ААА действует с 1.01.2006 по 31.12.2006
Условие 1 автомобиль ламборджини дъябло, условие действует с 1.01.2006 по 31.12.2006 лимит ответственности 700000 у.е. премия (ты оплатил) 30000 у.е.

Через месяц ты пришел и говоришь - ну ее на фиг эту жену водить не умеет пусть на такси ездит. Исключаем ее. Агент создает АДДЕНДУМ - дополнительное соглашение к полису. Имеем:

Полис №ААА действует с 1.01.2006 по 31.12.2006
Аддендум 1 к полису Полис №ААА действует с 1.02.2006 по 31.12.2006
Условие 1 автомобиль ламборджини дъябло, условие действует с 1.01.2006 по (ВНИМАНИЕ!) 31.01.2006 лимит ответственности 700000 у.е. премия (ВНИМАНИЕ!) (30000 у.е./365 * 31) условие отменившее данное - условие 2

Условие 2 введено аддендумом 1, автомобиль ламборджини дъябло, условие действует с 1.02.2006 по 31.12.2006 лимит ответственности 700000 у.е.
премия (25000 у.е./365 * (365-31))

Как видишь, имеем усложнение схемы но сразу две выгоды
1) На любую точку действия полиса без пересчета знаем его состояние. Грубо говоря делаем сечение на дату все условия которые им (сечением) режутся - действующие на данную дату
2) Удобство отмены. Ты передумал - отлично мы удаляем (конечно не удаляем - только меняем статус на аннулирован) аддендум. При этом удаляются все условия введенные аддендумом. При удалении условия просматриваются и восстанавливаются все условия имевшие ссылку на удаляемое как на условие прекратившее данное. В "твоем" случае условие 2 исчезнет а условие 1 снова растянется на весь год с соответствующим увеличением суммы.

Хоть что-то понятно? Я бы лично сам не понял ;-))) Тут надо долго и нудно на бумажке рисовать по переписке фиг объяснишь...

← →
Игорь Шевченко © (2006-04-14 10:19) [51]

Суслик © (14.04.06 00:59) [49]

Странно вы программы пишете. Ну да ладно.

← →
BiN © (2006-04-14 10:33) [52]

Пр
> Суслик © (14.04.06 00:59) [49]
>
>
> Правильно излагаешь.
> Но! Вот представь, если некий закон. Некие трактовки неоднозначны.
> На это существуют "толкования" разных уважаемых людей.
> Эти люди не министр финансов, не министр налогов и сборов,
> не дипутаты, принявшие закон. Это просто очень уважаемые
> люди

Программный продукт =
разработчик(архитектор, проектировщик, кодировщик) +
эксперт (бухгалтер, юрист, министр финансов).

Нет эксперта - нет варенья.

← →
Суслик © (2006-04-14 12:07) [53]

> Странно вы программы пишете. Ну да ладно.

В России живем.
Ты занимался ли разработкой именно бухсистем?

> [52] BiN © (14.04.06 10:33)

Ты говоришь именно про бухсистемы или вообще про то как надо делать? :)
Ты занимаешься разработкой именно бухсистем?

====================

> [50] Sergey Masloff (14.04.06 06:29)

> Хоть что-то понятно? Я бы лично сам не понял ;-))) Тут надо
> долго и нудно на бумажке рисовать по переписке фиг объяснишь...

Понял ну почти все - не первый год замужем :) Очень хорошо все рассказал (могу свою страховую фирму открывать :))
Но все же вопросы есть.

В твоем примере:
1. я заплатил 30000 уе в качестве премии.
2. из них "потратил" за первый месяц 2547,95 уе
3. т.е. у меня осталось 27452,05 уе.
4. потом я изменил условия срахования таким образом, что должен до конца года заплатить 25000 /365 * (365-31) = 22876,71.
5. т.е. твоя контора вернет мне 27452,05 - 22876,71 = 4575,34 уе.

Тут я вроде все верно понял.
Вопросы:
1. если отменить условие 2, то нужно будет доплатить? Верно ведь? Это то вы где храните? Т.е. где храните факт доплаты? Т.е. нужно будет менять исходный полис? Или будет еще аддендум с допалатой. Этого я из твоего рассказа не понял.
2. Правильно ли я понял, что вы вообще оплаченные документы (полисы) не меняете?

← →
Суслик © (2006-04-14 12:09) [54]

> [50] Sergey Masloff (14.04.06 06:29)

Т.е. я не могу понять, как соотносится фраза

> При возникновении новых данных старые не удаляются никогда
> - только записываются новые

и

> При удалении условия просматриваются и восстанавливаются
> все условия имевшие ссылку на удаляемое как на условие прекратившее
> данное

Т.е. они несколько противоречивы.

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

Суслик © (14.04.06 12:07) [53]

> В России живем.

Отмазка не канает.

> Ты занимался ли разработкой именно бухсистем?

Мне достаточно того, что этим занимается 1С, причем успешно

← →
Суслик © (2006-04-14 12:23) [56]

> Мне достаточно того, что этим занимается 1С, причем успешно

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

← →
Суслик © (2006-04-14 12:25) [57]

Еще хотел добавить к фразе

> Так и 1с живет, вернее из внедренцы в лице франчайзингов.

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

← →
Суслик © (2006-04-14 12:31) [58]

2ИШ
Еше хотел добавить.
У на не первый раз возникает разговор на эту тему. И не первый раз мне не удается объяснить свое мнение.
Вот представь, что у тебя есть эксперт А, сидящий в соседней комнате, жуткий профи. И есть эксперт Б сидящий в белом доме. Эксперт А читает бумажки эксперта Б. При том, что эксперт Б в общем-то не всегда профи. Но от услуг эксперта Б вы отказаться не можете. Эксперт А не всегда понимает, что говорит ему эксперт Б, т.к. тому пофигу - он на работе, ему нужно работать, деньги, деньги. Все остальное его не очень волнует. Как ты думаешь, какая до тебя в итоге дойдет информация? Каково будет ее качество и конструктивность?

Конечно, не все так плохо. Но есть моменты, где именно так - делай как знаешь на свой страх и риск.

← →
Игорь Шевченко © (2006-04-14 12:48) [59]

Суслик © (14.04.06 12:31) [58]

Добавь в программу настройку - сними с себя ответственность и переложи ее на конкретного пользователя - что может быть проще ?

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

> Добавь в программу настройку - сними с себя ответственность
> и переложи ее на конкретного пользователя - что может быть
> проще ?

Игорь, ты прав на все 100%. Кто же спорит.

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

Есть много других элементов закона, которые не поддаются однозначной алгоритмизации.

Есть системы в которых все вынесено в настройки - наприрмер sap r3 (это, правда, не бух система, а erp система, но не суть). В ней есть любые настройки. Там вообще программировать не надо - только мышкой кликай. У меня знакомый человек работал там. Он говорит, что за 3 года внедрения знал ровно 10% процентов от этой системы. Это говорит о монстроподобности таких систем. Реально ли такую написать? Не думаю.

Кстати по поводу доступности настроек пользователям. Кто реально данными настройками пользуется далеко не пользователи, а люди с зарплатами (понимаю, что не говорит ни о чем) до 4кб в месяц. Плюс к этому, конечно прилагается, соответствующий уровень знания. Ты предлагаешь такую работу взвалить на плечи пользователя?

Хотя, как мне кажется, для бухсистем такое вообще не применимо. Фиг такое сделаешь, т.к. в бухучете вариации зависимостей и алгоритмов очень большие. Пример. Сейчас (вроде в начале года поправки к Налоговому кодексу были) можно списывать 10% стоимости основного средства при постановке на учет. Разве можно это предугадать? Ну допустим даже можно - ввести настройку - столько процентов можно списать сразу. Но тут не ясно - куда их списывать: в амортизацию или в расходы. Тоже настройку делать? Так еще может быть такое, что данные расходы вообще не уменьшают налогооблагаемую прибыль (глупость, но мало ли) или еще какие условия? Поэтому набор настроек становится невменяемым - легче код написать.

← →
BiN © (2006-04-14 13:12) [61]

> Суслик © (14.04.06 12:07) [53]
>
>
> > [52] BiN © (14.04.06 10:33)
>
> Ты говоришь именно про бухсистемы или вообще про то как
> надо делать? :)
> Ты занимаешься разработкой именно бухсистем?

Говорю про разработку любых приложений на заказ.
Занимался в том числе и адаптацией все тех же 1с-предприятие/торговля-склад.
ТЗ пишется с участием эксперта от заказчика. Понятие "эксперт" - здесь весьмя условное и подразумевает человека, способного ответить на вопрос, что именно хочет заказчик вплоть до цвета тени мышки.
В случае же, если заказчик не знает чего хочет, программист должен или отказаться от проекта или (обычно при солидном инвестировании) суметь внушить заказчику желания оного.
Ясно, что бухгалтерия - скользкая тема и потому так много мальчиков-полупрограммистов сидят в малых и не очень фирмах, дописывая налету разные Trade Assistant-ы, 1С-ы и т.п. Чаще всего инициатором подобных изменений в программах выступают только что пришедшие бухгалтера или контрактники-аудиторы ("А вот мне нравится, когда так", "Там, куда мы сдаем, сказали, что нужно считать так" и т.д.).
Повторяю, это происходит в основном в малых фирмах, где нет профессионального юриста, способного, если надо, отстаивать каждую цифру.

← →
Игорь Шевченко © (2006-04-14 13:13) [62]

Суслик © (14.04.06 13:00) [60]

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

← →
Суслик © (2006-04-14 14:06) [63]

> Повторяю, это происходит в основном в малых фирмах, где
> нет профессионального юриста, способного, если надо, отстаивать
> каждую цифру.

Согласен на все 100%. Ты прав. Я хотел это добавить, но упустил.
Уверен, что в больших конторах есть юристы, способные принимать решения, т.е. уже быть не только юристами, а нести ответственность за принятие решений. В маленьких конторах такого обычно, наверное, нет. Есть один руководитель, который общается с заказчиком и пытается от него понять что ему нужно.

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

> [62] Игорь Шевченко © (14.04.06 13:13)

Действительно о разном говорим. Я те говорю, что бухгалтерия не бывает без человеческого фактора (даже дока-в несколько привел), а ты говоришь, что бывает. Тут истины не найдешь. Т.к. я уверен, что в бухучете такого не бывает (т.е. разработка по "правилам" без чел. фактора), то у меня выход один - на заниматься разработкой бухсистем вовсе :)

← →
Игорь Шевченко © (2006-04-14 14:19) [64]

Суслик © (14.04.06 14:06) [63]

> то у меня выход один - на заниматься разработкой бухсистем
> вовсе

Тоже выход. Потому что (ты уж меня извини, конечно), сдается мне, что при таком подходе вряд ли получится система, которой можно будет эффективно пользоваться. На Excel"е посчитать проще получится.

> [64] Игорь Шевченко © (14.04.06 14:19)

> ты уж меня извини, конечно

Да не проблема, тем более, что система работает и имеет огромные перспективы.

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

> неужели у вас есть такие эксперты, способные ответить на
> любой вопрос по бизнес-логике

Конечно.

Да, не там я работаю.

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

Моя твоя непонимай.
Там где я раньше работал, делалось так: МСБУ, РСБУ и НУ - разные планы счетов.
Проведение любого документа - ХП на сервере, почти для каждого типа документа своя, а там ужо от тебя зависит, что эта ХП будет делать, по какому плану счетов и какие проводки.
Без всяких J2EE и логики где-то еще помимо сервера БД.

> МСБУ, РСБУ и НУ

Мы от этой идеи отказались. Основной мотив, что на счетах МСФО и НУ можно держать только разницы. Для того, чтобы понять, например, сальдо по Основным средствам нужно взять сальдо по 01 + сальдо по НУ01
И т.д. На самом деле это оказывается выгодно тем, что по НУ и МСФО нужно держать немного записей.

Когда я плотно работал с МСФО (2003 год), то тот, кто мне ставил задачи утверждал, что в МСБУ без сложных проводок (когда, например, одна проводка, но 2 счета по дебету и 3 счета по кредиту) никак нельзя обойтись, а в РСБУ - без проблем. Соответственно, непонятно, какие разницы и в каком виде там вы будете хранить?

Впрочем, не имеет значение, что там держать - разницы, или все необходимое, главный вопрос в другом: как перенос логики с серевера БД на сервер приложений позволяет ускорить процесс разработки и внесения изменений в эту самую логику?

> но 2 счета по дебету и 3 счета по кредиту

Это гааповская форма проводки. Их всегда можно заменить российскими продовками.
Например, в РСБУ

Расчеты с поставшиком (часть)
1000 26 60
200 19 60

В гаапе тип такого было бы (я не помню точно как там записывается)

1000 26 -
200 19 -
1200 - 60

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

> Впрочем, не имеет значение, что там держать - разницы, или
> все необходимое, главный вопрос в другом: как перенос логики
> с серевера БД на сервер приложений позволяет ускорить процесс
> разработки и внесения изменений в эту самую логику?

Во. На этот вопрос забыл ответить :)
Тут все просто. Работая в среде ООП при качественном первичном проектировании фреймворка (в j2ee это уже сделано, нужно только адаптировать это под твои цели) ты получаешь средства заточенные под тебя, на языке высокого уровня. Поди плохо :)

ЗЫ. Я кстати j2ee не юзаю - у нас свой доморощенный аналог.

> Тут все просто. Работая в среде ООП при качественном первичном
> проектировании фреймворка (в j2ee это уже сделано, нужно
> только адаптировать это под твои цели) ты получаешь средства
> заточенные под тебя, на языке высокого уровня

Свежо предание о серебряной пуле, да верится с трудом.

> [75] Игорь Шевченко © (14.04.06 16:33)

Ну что значит "вериться"?
У тебя есть сомнения, что работать в ООП середе в общем случае в крупных прилоежения (порядка 1млн самописных строк) проще, чем без ООП?
Не пойму я тебя.

[73] Суслик © (14.04.06 16:20)
Я тоже так думал. Но. Попробуй напиши обычными проводками тип такого:
д20 400р.
д26 600р.
д19 200р.
к60 450р.
к76 650р.

когда не два к одному, а два к двум, два к трем и т.д.?
:)

[74] Суслик © (14.04.06 16:30)
Ну, незнаю. Зачем ООП при проведении документа? Возможностей PL/SQL хватало за глаза, думаю, T-SQL тоже-бы хватило.

> д20 400р.
> д26 600р.
> д19 200р.
> к60 450р.
> к76 650р.

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

> Ну, незнаю. Зачем ООП при проведении документа? Возможностей
> PL/SQL хватало за глаза, думаю, T-SQL тоже-бы хватило.

Знаешь, у нас так получилось, что изначально обладая гибкими возможностями ООП мы наплодили влякого удобнейшего функционала, от которого теперь отказаться не можем. Думаю, что данный функционал будет непросто сделать на SQL. Хотя вопро потребости в нем не очевиден. Возможно, что можно все делать проще так, чтобы все получалось на sql.

Суслик © (14.04.06 16:37) [76]

У меня есть сомнения в сути поста [74], кроме того, я увидел там слова "качественное первичное проектирование", а судя по твоим предыдущим постам о всяких там человеческих факторах, у меня зародились сомнения в качестве того самого проектирования.

> У тебя есть сомнения, что работать в ООП середе в общем
> случае в крупных прилоежения (порядка 1млн самописных строк)
> проще, чем без ООП?

Кстати, есть сомнения.

> [80] Danilka © (14.04.06 16:51)
> [78] Суслик © (14.04.06 16:47)
> > Пойми, это форма записи
>
> Дык, возьми листочек и попробуй расписать :)

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

> [79] Игорь Шевченко © (14.04.06 16:50)

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

---------
По поводу ООП. С чего это такие сомнения? Чем ООП не угодил.

Суслик © (14.04.06 16:54) [81]

> Нормально у меня все с проектированием :)

Прочитай собственные предыдущие посты и усомнись в этом факте.

> По поводу ООП. С чего это такие сомнения? Чем ООП не угодил.

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

Этта, качество моего проектирования скорее тема не для форума. Тут все равно ничего не докажу :)

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

А кто тебе говорил, что она должна быть компактной и прозрачной? Собственно я тоже так раньше думал - с ООП все должно быть просто. Потом почитал книжку Буча. Меня поразили его слова - если кто-то считает, что с объектами станет жить проще, то он заблуждается и несильно понимает суть ООП. Сейчас не помню в точности что он говорил по поводу того, что нужно понимать в ООП, если интересно посмотрю.
Мое же мнение, что ООП дает возможность масштабируемости решения (это не все, конечно, но это то, что пришло на ум). Т.е. когда ты загоняя логику в определенные границы, диктуемые библиотекой классов можешь сколь угодно развивать использование библиотеки вширь. API (набор необъектных функций) в этом смысле дают рядовому работнику-разработчику куда большие возможности пойти на лево от заданного курса партии. Оно тебе надо? А написав однажды серьезную ООП библиотеку, желательно с принципом Голливуда (не звоните, мы вам сами позвоним), ты ограничиваешь фантазию работника. Можешь брать хоть 100 чел - они будут писать так, как тебе нужно.

Уже второй год у увлечением читаю тематические диалоги ИШ и Суслика. Спасибо, господа, очень интересное и полезное чтение. Я серьёзно.

Суслик © (14.04.06 17:06) [83]

> А кто тебе говорил, что она должна быть компактной и прозрачной?
>

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

> А написав однажды серьезную ООП библиотеку, желательно с
> принципом Голливуда (не звоните, мы вам сами позвоним),
> ты ограничиваешь фантазию работника

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

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

> API (набор необъектных функций) в этом смысле дают рядовому
> работнику-разработчику куда большие возможности пойти на
> лево от заданного курса партии. Оно тебе надо?

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

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

Но не может быть таковым, если каждый из 100 человек пошел налево :)
ИМХО.

> тебе вообще не нужно 100 разработчиков - продвинутый генератор
> исходного кода и все задачи решены

Заменить человека, вернее его мозг, пока невозможно. ИМХО. Можно только дать человеку интсрумент с богатыми возможностями, который все же "ведет" человека по заданному курсу, который диктуется твоей библиотекой.
Примерно по этому принципу устроены многие сервера приложений. Человек пишет сервлет (плугин). Сервер же данный сервлет выполняет предоставляя сервлету богатые (иногда очень и очень) инструменты. При этом сервлет не может делать то, что ему захочется - даже в файл записать ничего не сможет, а вот воспользоваться готовым (и очень навернутым) механизмом распределенных транзакций - запросто.

Суслик © (14.04.06 17:38) [86]

Я несколько поясню, о чем речь в разговорах про "серьезную библиотеку". Вот возьмем, к примеру, Delphi - инструмент компонентной разработки. Много ли ты видел наборов компонент, относящихся к задачам какой-либо предметной области ? Обычно ведь задачи в областях более или менее одинаковые, по крайней мере, домены предметной области. Даже тот же ECO - это всего лишь механизм.

Вот мне стало интересно (я наборов компонент для предметных областей честно не видел), почему для интерфейса с пользователем или с базами данных или с внешними мирами наборы компонент есть, а для предметных областей - нету ? Может не везде ООП так уж победно шествует ? :)

> Но не может быть таковым, если каждый из 100 человек пошел
> налево

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

> Заменить человека, вернее его мозг, пока невозможно. ИМХО.
> Можно только дать человеку интсрумент с богатыми возможностями,
> который все же "ведет" человека по заданному курсу, который
> диктуется твоей библиотекой.
> Примерно по этому принципу устроены многие сервера приложений.
> Человек пишет сервлет (плугин). Сервер же данный сервлет
> выполняет предоставляя сервлету богатые (иногда очень и
> очень) инструменты. При этом сервлет не может делать то,
> что ему захочется - даже в файл записать ничего не сможет,
> а вот воспользоваться готовым (и очень навернутым) механизмом
> распределенных транзакций - запросто.

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

Игорь, наверное ты меня превратно понял. Поясню. Сначала напомню о чем речь - о ООП и о его ценности. Мы же это стали обсуждать?

В [74] я сказал, что в том же j2ee много сделано, но есно не для бухучета, а вообще для серверных приложений. При том, что j2ee все же диктует определенный подход к работе.

Я хочу сказать, что с ООП диктовать общий подход к работе проще, чем без него. Т.е. в ООП можно написать среду разработки, в который ТЫ сидишь, и которая по сути к тебе обращается. В API же ты САМ решаешь что и когда использовать и можешь решить это делать не так, как хочет твой начальник.

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

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

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

Суслик © (14.04.06 18:04) [88]

> Игорь, наверное ты меня превратно понял. Поясню. Сначала
> напомню о чем речь - о ООП и о его ценности. Мы же это стали
> обсуждать?

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

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

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

> Я хочу сказать, что с ООП диктовать общий подход к работе
> проще, чем без него. Т.е. в ООП можно написать среду разработки,
> в который ТЫ сидишь, и которая по сути к тебе обращается.
> В API же ты САМ решаешь что и когда использовать и можешь
> решить это делать не так, как хочет твой начальник.

> Но зачем велик изобретать - есть ООП, с ним делать среды
> разработки проще (уверен).

Зачем что-то рисовать, если можно скопировать
Зачем что-то копировать, если можно обвести
Зачем что-то обводить, если можно вырезать и наклеить.

Зачем делать среду разработки вместо того, чтобы решать конкретные задачи на купленной среде разработки.

> Зачем делать среду разработки вместо того, чтобы решать
> конкретные задачи на купленной среде разработки.

Потому, что я хочу на купленной среде разработки сделать свою среду и продавать сделанные на ней решения, которые мне будут делать 100 кодеров.

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