Я вас не понимаю. Вы хотите магазин написать? Или запустить? Если писать, то нужно реализовать каталог, корзину и оформление заказа. Это необходимый минимум.
Смысл таков: компания/категория/фотография.
Пример из жизни: "ООО Ромашка", категория "Свадебная съемка", фотография "Пара Алиса и Александр" должны превратиться в /ooo-romashka/svadebnaya-siemka/para-alisa-i-aleksandr/.
С точки зрения моделей это будет Company, Category (belongs_to Company), Photo (belongs_to Category).
Вообще я хотел бы немного модифицировать модель Photo, чтобы привязывать можно было бы к компании тоже.
Посмотрите в сторону готовых решений. Например Opencart, Magento. Я так понимаю вы хотите интернет-магазин или что-то подобное. Если обычный хомяк конторы, то поставьте WordPress.
Да, не все поля доступны через API. Некоторые требуют определенных прав доступа, например доступ к срезу adaccounts потребует валидации вашего приложения путем подачи запроса в фейсбук.
Я так понимаю, тут дело даже не в промисах, а в самой архитектуре затык. Обычно такие вещи стараются не делать со стороны клиента, т.к. возникают проблемы с безопасностью в cross-domain ajax.
@calliko просто нет смысла делать 3 таблицы вместо одной. Нужно просто хранить в users поля firstname (имя) и lastname (фамилия).
Как только твой сайт станет чуточку сложнее, то там users могут встречаться по нескольку раз и джоинить станет сложнее. Эти джоины скажутся на производительности.
Я бы не рекомендовал бы подобный дизайн, т.к. cardinality для указанных полей невысока и объединение данных в данном случае будет намного дороже. Вещи вроде выбора уникальных имен и фамилий решаются простейшим GROUP BY.
Данный пример показывает, что денормализация данных принесет в проект существенное упрощение и является допустимым инженерным решением.
