История изменений
Исправление marvin_yorke, (текущая версия) :
опишу боле подробно задачу и то, как я ее представляю. Пилю бэкенд приложения для небольшой студенческой кафешки. Зачем – вопрос другой, больше для опыта, чем с какой-то практической целью. Но хозяевам идея вроде понравилась.
Минимальное API описывается следующими запросами (примеры ответов - условные):
GET http://server/api/menu – все меню целиком: название + цена Схема:
{
categories: [
{
_id: 1,
name: '(sandwiches|salads|beer|...)',
items: [
{
_id: 1,
name: 'my tasty sandwich',
price: 100500
},
...
]
},
...
]
}
GET http://server/api/menu/:id – инфа об отдельном айтеме: фото, ингредиенты, whatever
{
_id: 1
name: 'my tasty sandwich',
price: 100500,
ingredients: 'bread, ham, cheese',
photo: 'public/photos/sandwich/1',
info: 'interesting fact about sandwiches'
}
POST http://server/api/orders – отправить заказ
{
name: 'Ivan Ivanov',
phone: '123-456',
date: '4/20/2013',
items: [
{
_id: 1,
count: 2
},
{
_id: 15,
count: 1
}
...
]
}
т.е. с одной стороны меню меняется сравнительно редко, зато часто запрашивается целиком, значит можно хранить детали каждого элемента внутри документа категории. Тогда клиенту мы отдаем весь список, а информацию по отдельному элементу он уже выберет из него сам. Вроде нормально. Но тогда встает вопрос о том, как такие иерархические документы апдейтить? И если в POSTе заказа указывать только айдишники, то для отображения заказа в админке нужно делать запрос по вложенным объектам. Можно добавить туда тоже поле категории, тогда будет чуть проще, хотя не факт.
Вобщем подкиньте какого-нибудь чтива по проектированию схемы данных в NoSQL
Исходная версия marvin_yorke, :
опишу боле подробно задачу и то, как я ее представляю.
Пилю бэкенд приложения для небольшой студенческой кафешки. Зачем – вопрос другой, больше для опыта, чем с какой-то практической целью. Но хозяевам идея вроде понравилась.
Минимальное API описывается следующими запросами (примеры ответов - условные):
GET http://server/api/menu – все меню целиком: название + цена
Схема:
[code]
{
categories: [
{
_id: 1,
name: '(sandwiches|salads|beer|...)',
items: [
{
_id: 1,
name: 'my tasty sandwich',
price: 100500
},
...
]
},
...
]
}
[/code]
GET http://server/api/menu/:id – инфа об отдельном айтеме: фото, ингредиенты, whatever
[code]
{
_id: 1
name: 'my tasty sandwich',
price: 100500,
ingredients: 'bread, ham, cheese',
photo: 'public/photos/sandwich/1',
info: 'interesting fact about sandwiches'
}
[/code]
POST http://server/api/orders – отправить заказ
[code]
{
name: 'Ivan Ivanov',
phone: '123-456',
date: '4/20/2013',
items: [
{
_id: 1,
count: 2
},
{
_id: 15,
count: 1
}
...
]
}
[/code]
т.е. с одной стороны меню меняется сравнительно редко, зато часто запрашивается целиком, значит можно хранить детали каждого элемента внутри документа категории. Тогда клиенту мы отдаем весь список, а информацию по отдельному элементу он уже выберет из него сам. Вроде нормально. Но тогда встает вопрос о том, как такие иерархические документы апдейтить? И если в POSTе заказа указывать только айдишники, то для отображения заказа в админке нужно делать запрос по вложенным объектам. Можно добавить туда тоже поле категории, тогда будет чуть проще, хотя не факт.
Вобщем подкиньте какого-нибудь чтива по проектированию схемы данных в NoSQL