Другими словами, чем дизайн схемы в Azure SQL должен отличаться от дизайна схемы для SQL на виртуальной машине или оборудовании? Какие дополнительные факторы должен учитывать администратор баз данных при разработке схем для баз данных Azure SQL и управляемых экземпляров?
Чтобы сузить круг вопросов, вы можете ограничить свой ответ выбором и дизайном первичного и кластерного ключа OLTP.
Для некоторого контекста для моего, по общему признанию, широкого вопроса я не нашел исчерпывающего ресурса для руководства по проектированию схемы в контексте функций масштабирования Azure SQL PaaS. При проектировании схемы базы данных с учетом Azure SQL необходимо определить, какие варианты проектирования позволят максимально увеличить полезность и упростить будущую реализацию функций масштабирования, включая сегментирование, синхронизацию данных SQL, >Прочтите горизонтальное масштабирование и гипермасштабирование?
Весьма вероятно, что "это зависит" является правильным ответом (но без зеленой галочки).
Тем не менее, я считаю это важным вопросом и хочу начать разговор здесь, в SO, и получить самые полезные ответы в одном месте.
Наиболее правильные ответы будут практичны в небольших масштабах, а также будут совместимы с функциями масштабирования Azure SQL без серьезного рефакторинга.
Другие подобные вопросы имеют устаревшие ответы и были опубликованы до того, как были введены многие из этих функций:
Требования к архитектуре для масштабирования таблиц/схем SQL Azure
