我应该将 MDF 文件附加到 SQL Express 还是将真实的部署脚本附加到 SQL Server？
我正在 ASP.NET 4.0（使用 EF 4.0）上构建一个类似博客的发布系统，我希望首先非常容易部署/备份。我正处于一个决策点：是否让系统在 SQL Server 中创建数据库并使用该数据库（传统上），或者在站点中拥有一个 App_Data MDF 文件并仅使用 SQL Express 附加到该文件。我知道 Express 版本的内存/大小限制，并且我不会达到限制，因为这不是性能关键型业务应用程序或任何严肃的东西。只是一个带有博客/文章/照片的简单 CMS（实际照片不保存在数据库中，只是它们的路径保存在 MDF 中），仅此而已。我认为使用 MDF 没有问题，但我也不是该主题的专家，因为我从未使用 MDF 文件工作/创建过网站。我总是部署在 SQL Server 上，但我不想处理用户/角色/权限，并且我最不想让用户因数据库设置而出现安装问题。
我应该带什么去？我在使用 MDF 时会遇到什么问题？建议？
I am building a blog-like publishing system on ASP.NET 4.0 (with EF 4.0) that I want to be very easily deployable/backupable in the first place. I am at a decision point of whether making the system to create a database in an SQL Server and use that (traditionally), or have a App_Data MDF file in the site and just attach to that one with SQL Express. I know the memory/size limitations of Express editions, and I won't be hitting the limits as this is not a performance-critical business application or any serious stuff. Just a simple CMS with blogs/writings/photos (actual photos are NOT saved in database, just their paths are saved in MDF) and that's it. I see no problem using MDF, but I'm not an expert on the topic too as I've never worked/created a website using MDF file. I always deployed on the SQL Server, but I don't want to deal with users/roles/permissions and the last thing that I want to have a user having installation problems due to database settings.
What should I go with? Any problems that I would face with MDF? Recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您使用 SQL Server Express - 这是一个服务器 - 我总是会选择“真正的”数据库方法：将您的数据库连接到服务器，通过其数据库访问它name，部署 SQL 脚本来更新它。
“从文件路径附加数据库”对我来说总是显得不成熟且相当混乱......
如果你不需要这种能力 - 调查SQL Server Compact Edition 这是一种仅包含一个文件的进程内数据库。它有其局限性 - 没有存储过程，不支持某些数据类型，例如
VARCHAR(MAX)或XML- 但对于更简单的场景，它是完美且易于使用的 -只需将其部署在您的应用程序中即可。它是单用户的，例如您不会在多个客户端之间共享数据，它是每个用户/应用程序自己的本地存储IF you use SQL Server Express - which is a server - I would always opt for a "real" database approach: attach your database to the server, access it by its database name, deploy SQL scripts to update it.
That "attach DB from file path" always seemed like a half-baked and rather messy kludge to me.....
If you don't need that kind of power - investigate SQL Server Compact Edition which is a one-file only, in-process database. It has its limitations - no stored procedures, doesn't support certain data types like
VARCHAR(MAX)orXML- but for easier scenarios, it's perfect and easy to use - just deploy it along your app. It's single-user, e.g. you don't share the data between several clients, it's a local store for each user/app on its own