softwarerЧто может дать.. да в общем достаточно много. Я как-то имел предметный разговор со знакомым, занимающимся системой управления произодством, реализованной на FB, и отметил изрядное количество.. не то чтобы извращений, но назовем так, сложных решений, которые в случае Oracle были бы необязательны
да, а особенно это актуально для операторов данной системы.
Действительно, например делать проводку счета гораздо приятнее, осознавая, что теперь она происходит по новому алгоритму, не содержащему извращений
locky
просто заменой ФБ на оракл - не обойтись, будет капитально
перепахан клиент.

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

Aki
Потому что Ора - это круто, это современно, это по нашему!
потому и надо переходить.. как же иначе?
Потому что ФБ ничто по сравнению с Ораклом, ФБ проигрявает во всем, даже в цене!
Что-то я не понимаю, это у нас еще один Yo! появился, или там просто смайлика не хватает ?

locky
поправьте, если ошибусь.
1. если вся логика на серваке, то клиент фактически - набор сторед проц
и гридов. замена сторед процев на другие - это половина клиента (не
забывая возможные настройки и т.п.) работа в принципе рутинная, но
чреватая ошибками. проверено переходом с BDE на ADO.
2. ну, тут на вкус... ФБ вроде как не умеет управлять транзакциями
изнутри ХП, значит управление идет с клиента. Оракл вроде как умеет, но
зуб даю - с клиента несколько проц вызываются - последовательно в рамках
одно транзакции, значит и с ораклом ситуация будет та же.. Некрасиво, ИМХО.
3. если таки делфин - никаких "классов доступа" - набор формочек. так шта...

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

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

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

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

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

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

softwarerНе слушайте всякую чушь. Толстый клиент без специальных классов запросто может быть правильным.

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

Anton Demidovdata level отделяют от business logiс level, если хотят первый легко заменить в будующем для поддержки другой БД без большого "перелопачивания" всего кода.
;) прочитайте на первой странице, там именно об этом речь и шла.

А вообще, меня удивляют люди, способные легко пренебречь признанными правилами конструирования по причине того, что имеются знакомые, которые не могут пройтись дебаггером по программе, и делающими далеко идущие выводы, причем не стесняются предлагать их всем остальным.
Видимо звучит весомо: "Да, делал я как советует там этот ваш Фаулер, полная лажа получается, сплошной источник проблем. Не читайте вы его"

Чем мощнее методика проектирования, тем более осторожно с ней надо обращаться, тогда и результат глядишь лучше получиться. Ваша мысль о том, что надо думать что делаешь, прямо скажем не является открытием Америки :)

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