Здравствуйте, Shmj, Вы писали:

S>Для бизнеса скорось и дешевизна разработки может быть важнее чем красота и даже мелкие удобства.

Проблема в том, что КАЖУЩАЯСЯ скорость — лишь начальное "головокружение от успехов". Прибежал, нажал кнопку, генератор вывалил сотню форм, в Вилларибо снова праздник.
А на деле, вся эта сгенерённая туфта 100% будет переделываться, донастраиваться и даже переписываться.
Просто даже смешно слышать слово "бизнес" и такое позорищное "программирование" — вы формами в переходах торгуете штоле??
Любая программа имеет минимум 5-летний срок службы, с ней работают десятки разных людей, всем нужно удобство, скорость, минимум движений и минимум ошибок. Программа требует постоянного улучшения (а значит должна быть высокая сопровождаемость продуманного кода). Где тут "скорость и дешевизна" влияют вообще?? Программа, которую пишут на скорость — это говно, а не программа просто по-определению.

Есть нормальная скорость разработки. Она может быть выше за счёт каких-то упрощений, но в целом качественная форма требует какой-то объективный минимум времени.
Если ты "побырому" нагенерил сотни форм — ты всё равно потратишь время на их анализ, корректировку настроек и новую перегенерацию. Хуже того — на большом объёме глаз просто замыливается и очевидные ляпы пролезают в релиз. И потом всё равно придётся кастомайзить код, потому что ЛЮБОЙ генератор далёк от совершенства.

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

Ну если вы пишете "автоматизацию мороженного ларька" — согласен, пострадавших мало. А если вы выходите на рынок, где ДЕСЯТКИ "формошлёпов" нагенерили своих "бухгалтерий", придётся писать что-то умнее, чем просто форма. Век тупых форм прошёл, объёмы инфы возросли кратно — в этих условиях конкурировать придётся интеллектом, скорость тут вообще никого не волнует.

S> В отображении данных добавят с помощью View на стороне базы.

Шта?? Причём тут view вообще? Ты считаешь, что все добавления имеют сложность "вычислить возраст по ДР"? Ну-ну...

S>Есть SQL CHECK Constraint:
S>Day1 int CHECK (Day1 >=1 AND Day1 <= 7)

Спасибо, поржал. И что дальше? Зачем мне вообще какие-то check Constraint? СУБД — это хранилище данных, всё остальное должно делаться на уровне апп-сервера, в удобном ЯОН в красивой IDE с анализаторами, профайлерами и т.п. Перестаньте уже носиться с этими атавизмами, век "программирования внутри СУБД" безнадёжно ушёл.


S>То о чем вы говорите — это сродни искусства. Искусство никогда не перестанет быть актуальным, однако же для большинства нужен просто функционал.

Ерунда. Уже ответил выше — таких "формошлёпских" приложений — тьма, только никому эти приложения-уроды не нужны. Победит только та программа, которая действительно ОБЛЕГЧИТ мою работу. Все могут вводить ФИО, не все умеют делать это оптимально. Да и "искусства" здесь минимум — есть десятки учебников по прагматичному проектированию UI, просто читай и внедряй.

S>Можно стены дома украсить картинами а можно "автоматически сгенеренными" фотообоями. Для большинства второй вириант доступнее.

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