创建数据库沙箱/测试区域，供用户运行假设场景
我试图弄清楚如何在我的新 Windows .NET/SQL Server 应用程序中创建“沙箱”区域。要求如下：
用户必须能够输入自己的数据，例如日期范围和定价等 用户必须能够针对此定价和日期范围数据运行多个场景。
上述数据结构也将在常规生产数据库中使用。因此，一方面我们将构建所有结构信息，另一方面每个用户（当前 10 到 30 人）需要能够创建自己的测试场景。
我不确定最好的方法是什么。我以为我可以为每个人提供 SQL Express 的本地副本，并确保本地副本反映生产数据的数据结构，但这看起来很混乱且不太理想。我也不想在生产服务器上创建许多数据库副本来为每个人提供自己的游乐场。
我在这里缺少什么明显的东西吗？我真正坚持的要求是用户能够输入自己的价格、日期范围等配置数据。他们需要根据自己的设置运行这些“假设”场景，但生产系统中不能有这种东西。
临时表可能会消失，因为这些场景可能需要跨会话保存，例如他们一天离开并第二天回来或其他什么。
任何指示或建议将不胜感激。
I'm trying to figure out how to create a "sandbox" area in my new Windows .NET/SQL Server application. Here's the requirements:
Users must be able to enter their own data for things like date ranges and pricing
Users must be able to run multiple scenarios against this pricing and date range data
The data structures above will also be used in the regular production database. So on the one hand we'll have all the structural information built, on the other every user (from 10 to 30 people currently) needs to be able to create their own testing scenarios.
What I'm not sure about is the best way to do this. I supposed I could give everyone local copies of SQL Express and make sure the local copies reflect the data structure of the production data, but this seems messy and less than ideal. I don't want to create many copies of the database on the production server to give everyone their own playground either.
Is there something obvious I'm missing here? The requirement that the users be able to enter their own configuration data for prices, date ranges, etc., is the thing I'm really stuck on. They need to run these "what if" scenarios against their own settings, but the production system can't have this kind of stuff in there.
Temp tables may be out because these scenarios may need to be saved across sessions, like when they leave one day and come back the next or whatever.
Any pointers or suggestions would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将所有内容分离到客户端数据库听起来是一件坏事。您希望能够在主应用程序数据库中运行这些场景。
只需专注于能够创建一个场景，暂时忽略多个用户。
您没有提及价格，但假设您有一个“产品”表。
让您的用户设置一个新场景并为其命名，然后为其分配一个 ID。
您可以在单独的模式（可选）中创建表 - scene.PRODUCTS 表，并让人们将有关产品的替代信息插入其中。然后，您可以根据场景 ID 和产品 ID 创建所有产品减去场景中的产品的 UNION。产品表，这将为您提供用户自定义定价信息 + 所有当前定价。
您可以针对这些场景设置安全性，以授予特定用户组的访问权限，或者让用户有选择地向他们授予访问权限。
如果系统繁忙，您还可以创建一个单独的数据库来执行此操作并每晚导入生产数据 - 您可以将所有数据保留在场景架构中，以便您的用户数据得以保留。运行此类预测可能会导致性能问题。
这都是我的理论思考——希望它有助于推动车轮转动。
Separating everything out into client databases sounds like a bad thing. You want to be able to run these scenarios in the main application database.
Just concentrate on being able to create a scenario and leave out the multiple users for a second.
You don't mention what the prices are for, but let's say you have a PRODUCTS table.
Let your user set up a new scenario and give it a name, which is then assigned an ID.
You could create table in a separate schema (optional) - scenario.PRODUCTS table and let people insert substitute information about products into it. Then you could create a UNION of all the PRODUCTS minus the ones that are in the scenario.PRODUCTS table based on the scenario ID and product ID, which will give you the users custom pricing information + all the current pricing.
You could set up security on these scenarios to give certain groups of users access to them, or let the user selectively grant access to them.
You could also create a separate database to do this in and import the production data nightly if it's a busy system - You would leave all the data in the scenario schema so your users data persists. Running these kind of forecasting things can cause performance issues.
This is all theoretical thinking on my part - hopefully it helps to get the wheels turning.