Comments 13
А почему nosql? Судя по решаемой задаче тут и xml и массивы с тестовыми данными подойдут.
Почему бы тогда сразу не перейти на MongoDb? (А МySQL использовать только там, где нужна сортировка и JOIN)
Странная идея — писать код вместо того, чтобы ставить ТЗ. Изучать задачу, анализировать конкурентов и т.п.
Я понимаю, раннее прототипирование и все такое, но никакое прототипирование не поможет, если в голове нет картинки того, ЧТО нужно получить на выходе.
Я понимаю, раннее прототипирование и все такое, но никакое прототипирование не поможет, если в голове нет картинки того, ЧТО нужно получить на выходе.
Не поддерживаю идею.
Если заказчик вам говорит, что нужно что-то переделать — так пусть платит за это.
Не вижу, как подобный подход сильно облегчает мне жизнь — если не наоборот — усложняет.
Если у вас требования настолько размыты или часто меняются координально и заказчик сначала хочет слона, а потом говорит — Нет, нет! А я хотел, чтобы вы муху слепили — вам все-равно придется всё переделывать.
Если заказчик вам говорит, что нужно что-то переделать — так пусть платит за это.
Не вижу, как подобный подход сильно облегчает мне жизнь — если не наоборот — усложняет.
Если у вас требования настолько размыты или часто меняются координально и заказчик сначала хочет слона, а потом говорит — Нет, нет! А я хотел, чтобы вы муху слепили — вам все-равно придется всё переделывать.
Я считаю что такой подход можно использовать как дополнение к нормальному проектированию БД. Структура связей и базовые поля все равно должны быть в виде ER-моделей, а вот всякие дополнительные атрибуты типа «имя любимой собачки» — можно выносить в сериализованные BLOB'ы
Использую похожий подход. На этапе прототипирования использую Hibernate с режимом hbm2ddl = update. В итоге схема базы генерится по моделям и в случае изменения схема происходит миграция.
Sign up to leave a comment.
Об одном подходе к построению БД на начальном этапе работ над web-проектом