Из вашего вопроса я понимаю, что интерфейс веб-сервиса выглядит примерно так:
/product/
/product/{ProductId}
/product/{ProductName}
/product/category/{CategoryId}
Поскольку вы спрашиваете, следует ли хранить CategoryName, я предполагаю, что он уникален (как и ProductName).
Я также предполагаю, что веб-служба обрабатывает случаи, когда продукты или категории прозрачно переименовываются (то есть путем предоставления перенаправления или любых других средств, которые позволяют вам обнаруживать это и обрабатывать его соответствующим образом). Если это не так, не рассматривайте хранение имен в качестве ссылок на продукты или категории - всегда используйте идентификаторы.
Я бы ответил на ваши вопросы # 1 и # 2 . Хотя уникальность ProductName и CategoryName технически позволит вам хранить их в вашем приложении в качестве уникальных идентификаторов продуктов и категорий, я бы предпочел вместо этого хранить их идентификаторы. Основным пунктом решения будет ваш носитель информации. Поскольку вы используете базу данных, а веб-сервис позволяет вам получать доступ к объектам по уникальным числовым идентификаторам, должны применяться правила нормализации базы данных - следовательно, вы должны хранить идентификаторы .
Выше, однако, предполагается, что вы используете реляционную базу данных - если вы используете базу данных NoSQL, я предполагаю, что сохранение имен вместо идентификаторов также будет приемлемым вариантом (по крайней мере, насколько я могу судить по моим текущим понимание решений NoSQL, к сожалению, у меня пока нет практического опыта работы с ними).
Относительно вопрос № 3 - Я бы придерживался соглашений об именах, которые вы уже используете в своей базе данных. Существует множество различных соглашений для именования таблиц и столбцов, поэтому я действительно сомневаюсь, что существуют какие-либо стандартизированные соглашения о том, как именовать столбцы, ссылающиеся на объекты веб-служб. Я бы назвал их в соответствии с вашими существующими соглашениями об именах и таким образом, чтобы назначение столбцов было понятно для всех, кто использует систему. Обратите внимание, что если есть вероятность, что в будущем вы будете использовать другие веб-службы, вам следует рассмотреть возможность сохранения названия службы в имени столбца, а не использовать общий префикс ws - например, AmazonProductId или AmazonCategoryId.
Я постараюсь выделить несколько пунктов из моего опыта, но я бы не назвал их лучшими практиками - просто темы для размышления.
По своему опыту я обнаружил, что полезно обрабатывать данные из веб-служб таким же образом, как и данные из базы данных - по крайней мере, с точки зрения приложения, где ваш уровень хранения будет абстрагирован от логики приложения. Под этим я подразумеваю, что вам следует подумать и подготовиться к подобным сценариям независимо от того, является ли ваш носитель данных базой данных или веб-службой. Так же, как базы данных, веб-сервисы могут выходить из строя, у обоих могут быть повреждены данные или целостность, так как оба потребуют очистки или обработки данных при вводе.
Кэширование данных должно быть элементом, который занимает важное место в вашем списке - помимо очевидных причин производительности, он может позволить вам справляться с простоями веб-службы (в той степени, в которой данные ограничены ты кешируешь).
Примером может служить то, что ваше приложение отображает список наиболее часто покупаемых продуктов в вашем приложении. Если ваше приложение хранит только идентификаторы продуктов, вам нужно будет сделать один или несколько запросов к веб-службе, чтобы получить названия всех продуктов, которые необходимо отобразить в списке. Если вы кэшируете названия продуктов локально или в своей базе данных, вы достигнете лучшей производительности, сохраните свои ресурсы и у вас также будет аварийный сценарий на случай, если веб-служба выйдет из строя.
Ссылочная целостность - еще один важный аспект, который следует учитывать при работе с веб-службами.Поскольку веб-служба полностью отделена от вашей базы данных, у вас нет возможности создавать внешние ключи, как это было бы в решении только для базы данных.Это означает, что изменения данных в веб-службе (т. Е. Обновления или удаления продуктов) могут нарушить целостность данных в вашей базе данных.
Что касается ссылок , они зависят в основном от типа веб-службычто вы собираетесь использовать (вы не указали, какой сервис вы будете использовать).Если сервис основан на принципах REST, я могу порекомендовать Restful Web Services от Леонарда Ричардсона и Сэма Руби .Несмотря на то, что он не сфокусирован на интеграции приложений / сервисов как таковой, он является отличным введением в REST.