угу, прям в душу заглянул.

На мой взгляд, качество ПО за последние лет 5 сильно упало, и продолжает падать .

Причем во всех областях. Надо ввести закон, чтобы программисты обязательно добивались работоспособности своих программ на машинах типа p133 32 MB. :)
Чтобы программисты БД запросики свои зело оптимизили.
Чтобы программисты С++ вконце концов начали думать головой, а не тем, на чем сидят, или нафик ваще из отрасли. Хожу по сайтам типа codeproject, codeguru, sourceforge. Зачастую все больше вижу тихого ужаса, и все меньше чего-нить стоящего.
Развращает быстрая железка, позволяет девелопить спустя рукава...

2 Varan

Я же говорю - старым дедовским способом. Написал че-нить, проверь на медленной машине на адекватность, сразу узкие места найдешь. Зачастую вполне очевидные, но незаметные невооруженным глазом на быстрых машинах. Когда большое количество таких мелочей копиться в большом проекте - ясен пень снижается общая производительность. Это самый простой способ и не занимает много времени. В моем подходе один недостаток - не у всех есть доступ к старым машинам.
Гораздо более тяжелый другой способ - все время задаваться супер-целью нахождения максимально эфективного результата. Способ неэффективный, т.к. как известно только 10% от общего кода занимают 90% общего времени выполнения, т.е. отлавливать надо именно "узкие" места. Зачастую опытный программер видит эти узкие места издалека. Но все чаще наблюдаю картину, когда какой-нить чел хвастается только тем фактом что он СДЕЛАЛ и у него ЗАРАБОТАЛО. :) В далекие 92-е этот вопрос даже не обсуждался, всегда стоял вопрос КАК ЗАРАБОТАЛО, т.к. техника подхода требовала.

Не думаю, что сейчас этот вопрос утратил актуальность. Если в средней оптово-розничной фирме 30-50 одновременно работающих девочек строчат как из пулемета накладные (каждая по 300 и более строк), база пухнет по нескольку метров в день, то тут призадумаешься. Можно идти в лоб и покупать какой-нить супер-пупер 4-х головый сервак за $5000, а можно и pIII обойтись (это все происходило в 2001-м).

2 Varan

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

2 Varan

Процитирую себя же из той же ветки:

Какие сейчас наиболее популярные направления борьбы со cложностью:

1. Entity engin - использует БД как просто место хранения состояний объектов. О таких вещах, как ограничение целостности, речь не идет. Мощь встроенных инструментов БД практически не используется. Зато очень удобно проектировать бизнесс-логику произвольного уровня сложности.

2. База сама в себе. Интерфейс с пользователем - через набор хранимых процедур, инкапсулирующих всю необходимую логику приложения. Часто применяемый подход настоящих "зубров" БД. И совершенно не получается именно так спроектировать простейшую бухгалтерскую систему, где можно настраивать формулы и алгоритмы для автоматического расчета проводок, потому как на VB или чем-то подобном бухгалтер вполне может написать расчетный скрипт, а вот на Transact SQL - никогда! К тому же, полное проектирование приложения на стороне БД требует гораздо большей квалификации ... <кусь>

3. Смешанный тип - часто используется в 3-х звенке. Что удобно вычислять на сервере БД - вычисляют на БД, что не удобно - то на сервере приложений. При взгляде на такое приложение вообще обычно трудно выделить такие понятия как "концепция приложения". Зачастую больше подходит "писанина", потому как большинство проблем решены "по месту" (так собирались первые автомобили). Не программный продукт, а сборник компроммиссов. Толкаемые Microsoft "современные" решения как раз из этой области. Приходиться задействовать гораздо больше людей, чем если бы это было нужно используя варианты 1 или 2.

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

Поищи в и-нете по entity engine, тонна материала и различных точек зрения. Народ пока "зреет" ...

Да, если хватает людей, причем ситуация такова, что есть "полный" набор узкоспециализированных спецов: (БД, ООП, GUI), однозначно пишите 3-х звенку. (п.3.)

один из примеров:

http://intersystemskorea.co.kr/analysts/2001symp/Israel/Tony_Grover_BuildingDBIndepApps.ppt