允许用户在 ASP.NET 网站上创建新类别和字段
我们有一个数据库驱动的 asp.net /sql 服务器网站,并想研究如何允许用户创建新的数据库类别和字段 - 这疯狂吗?有没有这样的有机网站的例子 - 事实上我还没有看到任何可能表明我是? 对允许管理员进行一定程度控制的最佳方法感兴趣。
We have a db driven asp.net /sql server website and would like to investigate how we can allow users to create a new database category and fields - is this crazy?. Is there any examples of such organic websites out there - the fact that I havent seen any maybe suggest i am?
Interested in the best approach which would allow some level of control by Admin.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我已经使用字典表而不是更传统的表来实现这些功能。
字典表可能看起来像这样:
那么,传统表中的一行将变成多行:
传统方式(当然我不是在编造 GUID):
...将变成多行字典:
您的 GUI 可以搜索 itemid=1 的所有记录并获取所需的所有列。
或者它可以搜索
itemid 所在的所有记录(select itemid from tblDictionary where column='Type' and value='Car'
来获取所有汽车的所有列。理论上,您可以将用户- 定义的类型放入同一个表中 (Type='Type') 以及该 Type 具有的用户定义列 (Type='Column', Column='ColumnName') 这就是排序依据列出现的地方 -帮助构建 GUI正确的顺序,如果您不想依赖其他东西,
但是,很多时候,我觉得将用户定义的字典元素存储在字典中有点太多了。可以是单独的表,因为您在设计时就已经知道它们需要什么结构:)
此方法永远不会具有传统表所具有的报告速度或质量。这些通常要求开发人员预先了解结构。但如果要求是灵活性,这可以完成这项工作。
通常,最初是我网站的用户定义区域,后来有一个项目来标准化报告数据等。但这允许用户以有限的方式开始并在与开发人员合作之前确定他们的需求。
毕竟,我只想提几个可能适合您或可能不适合您的选项:
他们自己的清单就是这样。
允许多个同时编辑也可以达到目的。
也可以用作这样的单表数据库。
I've implemented things along these lines with a dictionary table, rather than a more traditional table.
The dictionary table might look something like this:
So, then, what would have been one row in a traditional table would become multiple rows:
Traditional Way (of course I'm not making up GUIDs):
...would become multiple rows in the dictionary:
Your GUI can search for all records where itemid=1 and get all of the columns it needs.
Or it can search for all records where
itemid in (select itemid from tblDictionary where column='Type' and value='Car'
to get all columns for all cars.In theory, you can put the user-defined types into the same table (Type='Type') as well as the user-defined columns that that Type has (Type='Column', Column='ColumnName'). This is where the sortby column comes into it - to help build the the GUI in the correct order, if you don't want to rely on something else.
A number of times, though, I have felt that storing the user-defined dictionary elements in the dictionary was a bit too much drinking-the-kool-aid. Those can be separate tables because you already know what structure they need at design time. :)
This method will never have the speed or quality of reporting that a traditional table would have. Those generally require the developer to have pre-knowledge of the structures. But if the requirement is flexibility, this can do the job.
Often enough, what starts out as a user-defined area of my sites has had a later project to normalize the data for reporting, etc. But this allows users to get started in a limited way and work out their requirements before engaging the developers.
After all that, I just want to mention a few more options which may or may not work for you:
their own lists in this way.
to allow multiple simultaneous edits would also serve the purpose.
would also serve as single-table databases like this.