Об одном подходе к построению БД на начальном этапе работ над web-проектом

[DeusModus]

А почему nosql? Судя по решаемой задаче тут и xml и массивы с тестовыми данными подойдут.

[k12th]

Чисто теоретически, тут подойдет и файловая система, которую можно представить, как иерархическую БД:)
А теперь вопрос: чем отличается СУБД от текстового (или xml, или csv) файлика?

[sdevalex]

Думаю вы имели введу РСУБД… :)

[k12th]

Не только реляционную, хотя они отличаются заметнее всего.

[vanxant]

Скоростью работы, скоростью разработки, надежностью хранения.

[k12th]

Да, а еще готовыми высокоуровневыми API для выборки, сортировки и т.д. Каковые API снимают с их пользователя кучу забот по написанию и поддержке подходящего DSL, обеспечения целостности и т.п.

[sdevalex]

Почему бы тогда сразу не перейти на MongoDb? (А МySQL использовать только там, где нужна сортировка и JOIN)

[sdevalex]

Я так делаю в своем личном проекте (сортировка и JOIN там ненужны)…

[munkie]

В монго все нормально с сортировками

[vanxant]

Странная идея — писать код вместо того, чтобы ставить ТЗ. Изучать задачу, анализировать конкурентов и т.п.
Я понимаю, раннее прототипирование и все такое, но никакое прототипирование не поможет, если в голове нет картинки того, ЧТО нужно получить на выходе.

[So1]

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

Если у вас требования настолько размыты или часто меняются координально и заказчик сначала хочет слона, а потом говорит — Нет, нет! А я хотел, чтобы вы муху слепили — вам все-равно придется всё переделывать.

[RomanL]

Я считаю что такой подход можно использовать как дополнение к нормальному проектированию БД. Структура связей и базовые поля все равно должны быть в виде ER-моделей, а вот всякие дополнительные атрибуты типа «имя любимой собачки» — можно выносить в сериализованные BLOB'ы