允许用户在 ASP.NET 网站上创建新类别和字段

发布于 2024-11-25 19:39:13 字数 126 浏览 0 评论 0原文

我们有一个数据库驱动的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

阪姬 2024-12-02 19:39:13

我已经使用字典表而不是更传统的表来实现这些功能。

字典表可能看起来像这样:

create table tblDictionary
(id      uniqueidentifier, --Surrogate Key (PK)
 itemid  uniqueidentifier, --Think PK in a traditional database
 colmn   uniqueidentifier, --Think "column name" in a traditional database
 value   nvarchar,         --Can hold either string or number
 sortby  integer)          --Sorting columns may or may not be needed. 

那么,传统表中的一行将变成多行:

传统方式(当然我不是在编造 GUID):

ID     Type  Make      Model     Year    Color
1      Car   Ford      Festiva   2010    Lime

...将变成多行字典:

ID    ITEMID    COLUMN     VALUE    
0     1         Type       Car
1     1         CarMake    Ford
2     1         CarModel   Festiva
3     1         CarYear    2010
4     1         CarColor   Lime

您的 GUI 可以搜索 itemid=1 的所有记录并获取所需的所有列。
或者它可以搜索 itemid 所在的所有记录(select itemid from tblDictionary where column='Type' and value='Car' 来获取所有汽车的所有列。

理论上,您可以将用户- 定义的类型放入同一个表中 (Type='Type') 以及该 Type 具有的用户定义列 (Type='Column', Column='ColumnName') 这就是排序依据列出现的地方 -帮助构建 GUI正确的顺序,如果您不想依赖其他东西,

但是,很多时候,我觉得将用户定义的字典元素存储在字典中有点太多了。可以是单独的表,因为您在设计时就已经知道它们需要什么结构:)

此方法永远不会具有传统表所具有的报告速度或质量。这些通常要求开发人员预先了解结构。但如果要求是灵活性,这可以完成这项工作。

通常,最初是我网站的用户定义区域,后来有一个项目来标准化报告数据等。但这允许用户以有限的方式开始并在与开发人员合作之前确定他们的需求。

毕竟,我只想提几个可能适合您或可能不适合您的选项:

  1. 如果您有 SharePoint,用户已经能够创建
    他们自己的清单就是这样。
  2. 以这种方式保存的共享文件夹中的 Excel 文档
    允许多个同时编辑也可以达到目的。
  3. Excel 文档,存储在网络服务器上并通过 ODBC 访问
    也可以用作这样的单表数据库。

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:

create table tblDictionary
(id      uniqueidentifier, --Surrogate Key (PK)
 itemid  uniqueidentifier, --Think PK in a traditional database
 colmn   uniqueidentifier, --Think "column name" in a traditional database
 value   nvarchar,         --Can hold either string or number
 sortby  integer)          --Sorting columns may or may not be needed. 

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):

ID     Type  Make      Model     Year    Color
1      Car   Ford      Festiva   2010    Lime

...would become multiple rows in the dictionary:

ID    ITEMID    COLUMN     VALUE    
0     1         Type       Car
1     1         CarMake    Ford
2     1         CarModel   Festiva
3     1         CarYear    2010
4     1         CarColor   Lime

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:

  1. If you have SharePoint, users already have the ability to create
    their own lists in this way.
  2. Excel documents in a shared folder that are saved in such a way
    to allow multiple simultaneous edits would also serve the purpose.
  3. Excel documents, stored on the webserver and accessed via ODBC
    would also serve as single-table databases like this.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文