В последнее время я много размышлял и узнавал о формах, пытаясь добавить расширенные расширения к Spree ECommerce Platform : подписки, события, пожертвования и всевозможные опросы.
Каждый пример, с которым я когда-либо сталкивался (в блогах , в документах , в скринкастах , в исходном коде и т. Д. ) создавать формы из моделей , но они никогда не переходят к чему-либо полуструктурированному или неструктурированному (или просто действительно динамичному). Таким образом, у вас есть такие формы, как:
- Контактная форма (модель пользователя, может быть разделена на модель адреса)
- Регистрационная форма (модель пользователя, модель учетной записи, модель адреса и т. Д.)
- Форма блога (модель сообщения, модель тега и т. Д.)
- Форма оформления заказа (модель доставки, модель заказа, модель LineItem и т. Д.)
Все это имеет смысл: они являются кульминацией десятков тысяч, даже миллионов человеко-часов. Тонны людей постепенно абстрагировали эти вещи в почти универсальные «модели», которые можно было бы сохранить в таблице базы данных. Теперь мы все создаем для них модели и создаем для них таблицы базы данных.
Но есть много других вещей, которые нельзя свести к этим конкретным моделям. Такие вещи, как опрос для определенного события, с полями формы, такими как:
- Вы беременны?
- Сколько у вас детей?
- Вы когда-нибудь болели?
- Какая ваша самая быстрая миля?
Если бы мы начали сохранять эти вещи в базе данных в виде таблиц, у нас было бы 100 и 1000 таблиц базы данных, по одной на каждый набор вопросов или «опрос».
Так что я думаю, что должен быть момент, когда вы прекращаете создавать конкретные модели, такие как «Пост» и «Заказ», и начинаете просто делать модель «Форма» или «Опрос» (Форма ~ Опрос ~ Анкета) до некоторой степени).
Все будет сводиться к этим нескольким моделям:
- Обзор
- Вопрос
- Ответ
- ResponseSet (ответы на вопросы в опросе)
- Ответ (конкретный ответ в наборе ответов)
И из тех, что вы можете создать любой тип "Форма" вы хотели.
Итак, мой вопрос в основном: когда вы в наиболее практичных повседневных клиентских проектах прекращаете создавать формы с кучей моделей в них (форма «Оформить заказ» - это форма для «Заказа») в основном в Spree, но это легко требует 10 моделей баз данных), и просто начать использовать вопрос / ответ или поле / ввод или ключ / значение? Практически
Я просто искал что-то вроде "когда мы создавали нашу систему онлайн-обучения, мы не закончили тем, что создали группу объектов SomeTutorialModel, которые расширяют TutorialModel, потому что это добавило бы слишком много таблиц в нашу базу данных. Вместо этого Мы просто использовали Surveyor gem". Что-то в этом роде:).
Существует не так много для этого полуструктурированного типа данных, но много, когда вы можете свести его к чему-то сверх конкретному.
Кажется, что если бы вы использовали базу данных документов, такую как CouchDB, вы в конечном итоге могли бы создавать, например, все виды объектов модели в ruby, и могли бы получить их с помощью некоторых хитрых приемов просмотра . Но с MySQL и тому подобным это кажется безумным.