场景是我正在重建一个目前是SQL和经典asp的应用程序。但是，我想稍微更新一下以利用Azure表。我知道Azure SDK有Dev Fabric存储可用，我想可以选择在我的所有机器上安装它。
但是我想知道是否存在一种模仿Azure表的“侵入性”方式。对象DB或文档DB是否提供了可用于早期原型设计的合理传真。或者是从它们迁移到Azure SDK表只是比它的价值更令人头疼？
答案 0 :(得分：2)
在我看来，你应该完全跳过假的Azure表。甚至MS开发存储也不能完全匹配事物在云中的实际运行方式。您可以获得1M交易，1美元，1GB存储空间，0.15美元，每GB数据输入/输出0.15美元。如果你只是原型设计，那就危险地生活，花10美元。
如果您刚开始使用Azure表，并且尝试使用开发存储或其他代理，那么您可以节省大量时间来重新编写代码以对抗真实内容。
如果你只是使用表而不是队列，blob 10美元将会有很长的路要走。
答案 1 :(得分：0)
每个Azure“项目”（类似于Azure帐户）最初仅限于5个托管存储帐户。假设您有一个用于实际内容的存储帐户，另一个用于诊断。现在假设您需要分别为每个存储帐户设置开发帐户和质量检查存储帐户，这样您就不会损坏生产数据。您现在已经用完了存储帐户（在上面的方案中，您需要6个托管帐户）。您需要致电Microsoft并要求增加此限制......
相反，如果您在开发/本地测试期间使用Dev Fabric作为表格，那么您将释放Azure存储帐户（用于开发的帐户 - 您仍然希望QA存储帐户位于Azure中，而不是Dev Fabric）。
您不能依赖Dev Fabric进行存储的一种情况：性能/负载测试。