mcureenab
Меня не удивляет, когда люди не умеют думать. Меня не удивляет, когда люди не умеют читать. Но меня продолжает удивлять, когда вроде бы умеющие думать люди не умеют читать.

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

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

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

На самом деле все очень просто. Как Вы наверняка помните, "лень - двигатель прогресса". Проблема в том, что есть два принципиально разных вида лени:

1. Мне лень делать плохо и потом мучиться-переделывать.
2. Мне лень делать хорошо.

Так вот, двигателем прогресса является только одна из них.

mcureenabЕсли дизтопливо оставляет пятна на краске, то нужно либо бензиновый двигатель ставить, либо краску менять и т.п..
Все правильно. Собственно, как раз иллюстрация к сказанному выше - если есть проблема, надо либо исключить контакт топлива с краской, либо найти устойчивую краску того же цвета, либо .. либо .. либо .. и только на самом последнем этапе - прийти к пользователю и сказать:

mcureenabCредства разработки класса Builder
Это, простите, что такое?

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

Собственно, представьте себе, что у Вас в СУБД выполняются:


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

mcureenabПроектируя части системы с этим фактом нельзя не считаться. Если встречное движение архитектора БД и дизайнера UI позволяет создать сбалансированное решение, то почему бы не делать так?
Потому что оно будет не "сбалансированным", а "сильно связанным как раз в том месте, где этого не следует делать".

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


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

mcureenabС++ Builder, Delphi, Oracle Forms.
Из этих средств я хорошо знаю одно и имею неплохое представление о другом. Будьте так любезны, не рассказывайте о них сказки.

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

mcureenabи лень - "я за 1 час набросаю рабочее приложение и займусь следующим".
Угу. "Продам его, получу деньги, забуду все контакты этого клиента, не буду отвечать на его письма-звонки, а буду заниматься тем, чтобы пытаться впарить следующее приложение следующему клиенту".

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

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

mcureenabВ самом незатейливом случае, я перетаскиваю на форму таблицу Country и сдаю работу.
А кто Вам сказал, что это таблица? Перетащили? Хорошо. Сдали работу? Хорошо. После чего я меняю только БД, и угадайте с трех раз - будет Ваш exe-шник работать со вьюхой Country или нет?

mcureenabЭто как раз пример несбалансированного решения.
То есть Вы признаете, что Ваш путь соответствия ведет к несбалансированному решению? Замечательно, давайте тогда вернемся к тому месту, где Вы объявили такое решение сбалансированным, и попробуйте дать какой-нибудь другой ответ в том месте.

mcureenabЛожась костьми на ниве независимости БД и GUI мы создаём такие условия, что любое изменение БД требует офигенных затрат
Совершенно безосновательное утверждение.

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

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

mcureenabВ данном случае я говорю не о трёхзвенной архитектуре, где промежуточный слой является неотъемлимой частью системы и в свою очередь создаётся из готовых блоков, а о старом добром клиент-сервере.
А в чем разница? Почему в трехзвенке он "создается из готовых блоков", а в КС нет? Вы это про Oracle Forms?

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

mcureenabЯвляясь мостом, БД и СУБД должна так или иначе учитывать требования всех клиентов. В одном случае ускоряя GUI приложения на 1сек, мы можем пожертвовать несколькими часами работы низкоприоритетного фонового процесса, и т.д.
Именно так. Это одна из причин, из-за которых связь между "кирпичиками" клиента и сервера вовсе не один к одному.

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

Сахават ЮсифовДа бросьте.
Это для меня нехарактерно. Я, если Вы еще не заметили, жуткий зануда.

Простите за нескромный вопрос, Вы уверены, что с той стороны логина - именно Вы и примерно в том же состоянии, в котором обычно пишете в форум?