如何设置有关共享项目的组织特定数据元素？
第一次发帖，请多多包涵。
注意：我已经查看了条目#20856（如何实现标记），但感觉这是不同的，因为我正在考虑的标记方法是我的应用程序中特定于组织的。我希望有人可以确认我要去的方向或指出一些其他选择。
（背景）我们正在构建一个 Web 应用程序，使不同的组织能够了解其在不同位置的库存。该数据库存储用户、组织、站点和项目，并且存在从站点和项目到组织的链接，使我们能够确定向哪些用户显示哪些项目/站点（基于他们的组织）。
两个（或更多）组织希望使用门户来检查（例如）洛杉矶仓库中小部件 A 的库存状态是很常见的。那部分很好。然而，不同的组织还跟踪有关小部件 A 的独特信息。例如，组织 1 希望跟踪每个项目的颜色、体积和主要供应商。组织 2 希望跟踪每个商品的颜色、库存类型、库存周期、买家代码。我想避免这样的情况：我必须有一个表加载所有这些可能的字段，然后找出哪些组织使用哪些字段。
我正在考虑使用类似标签的东西，但添加标签类别，并在组织级别定义标签类别。因此，基本表结构类似于：
Table: OrgTagCategory
字段：OrgId、TagCategoryId、CategoryTitle
表：OrgTag
字段：OrgId、TagCategoryId、TagId、TagTitle
表：OrgItemTag
字段：OrgId、ItemId、TagId
然后，当用户登录主仪表板时，网格将包含其适当的项目字段作为网格中的列。因此，从上面的示例中，组织 1 将看到商品编号、描述（将为所有人显示）、颜色、数量和主要供应商。组织 2 将显示商品编号、描述、颜色、库存类型、库存周期、买家代码。
我是否想得太多了，或者是否有一个我缺少的更简单的方法？衷心感谢所有想法/反馈。
First post, please be kind.
NOTE: I have reviewed entry #20856 (how to implement tagging) but feel this is different due to the fact that the tags method I'm considering is organization specific in my app. I’m hoping someone can confirm the direction I’m going or point out some other options.
(background) We are building a web application that gives different organizations visibility to their inventory in different locations. The database stores users, organizations, sites, and items and there are links from sites and items to organizations that allow us to determine which items / sites to show to which users (based on their organization).
It is common for two (or more) organizations to want to use the portal to check on the stock status of (for example) Widget A in the Los Angeles Warehouse. That part is fine. However, the different organizations also track unique information about Widget A. For example, Org 1 wants to track the color, volume, and primary vendor for each item. Org 2 wants to track Color, Stock Type, Inventory Cycle, Buyer Code for each item. I want to avoid a situation where I have to have a table loaded with all these possible fields and then figure out which organizations use which fields.
I’m considering using something along the lines of tags, but adding a tag category, and having the tag category be defined at the Org level. So, the basic table structure would be something like:
Table: OrgTagCategory
Fields: OrgId, TagCategoryId, CategoryTitle
Table: OrgTag
Fields: OrgId, TagCategoryId, TagId, TagTitle
Table: OrgItemTag
Fields: OrgId, ItemId, TagId
Then, when the user logged in the main dashboard the grid would include their appropriate item fields as columns in the grid. So, from above example, Org 1 would see Item#, Description (would be shown for all), color, volume, and primary vendor. Org 2 would be shown Item#, Description, Color, Stock Type, Inventory Cycle, Buyer Code.
Am I overthinking this or is there a simpler method of doing this that I’m missing? All thoughts / feedback sincerely appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这应该没问题，但您多余地存储了
OrgId。此外，标签和组织之间似乎可能存在一些重叠（实际上可能有很多重叠）。我的做法如下：
Table: OrgTag
字段：OrgId、TagId
表：标签
字段：TagId、TagTitle
表：ItemTag
字段：ItemId、TagId
这样，每个组织都会与其感兴趣的标签相关联，但不会有多余的标签。由多个组织使用的给定标签只会在 OrgTag 中获取一堆行，而不是在 Tag 中获取具有相同 TagTitle 的多行。
如果每个组织有多个标签类别，您只需要一个表
OrgTagCategory。但您还没有将这种额外的关联描述为一项要求。That should be no problem, but you're storing the
OrgIdredundantly. Also it seems like there could be some overlap (probably a lot of overlap, realistically) between tags and orgs.Here's how I'd do it:
Table: OrgTag
Fields: OrgId, TagId
Table: Tag
Fields: TagId, TagTitle
Table: ItemTag
Fields: ItemId, TagId
This way each org is associated with the tags it's interested in, but you don't have redundant tags. A given tag that's used by multiple orgs just gets a bunch of rows in OrgTag, instead of multiple rows in Tag with the same TagTitle.
You'd only need a table
OrgTagCategoryif there were multiple tag categories per org. But you haven't described this extra association as a requirement.根据您的描述，我绘制了一个简化的模型，并将其与观察模式< /a>。这应该使您能够跟踪各种项目属性和用户查看它们的首选项。诚然，
Preference表可能会变得很大，但数据无论如何都必须存储在某个地方，并且您可以使用 sql 检索它，这简化了业务层。- 组织和个人是用户的类型。
User表具有所有用户 共有的列，而Organization和Person表具有每个用户特有的列。- 库存物品（小部件类）可以在多个站点（仓库）找到；一个站点存储许多项目。
- 一个项目属于一个用户；一个用户可以拥有许多物品。
- 测量和特征是观察类型。 测量是一种数值观察，例如高度。 特征是一种描述性观察，就像颜色一样。
-观察属于特定类型（高度、重量、颜色），可以有多个相同观察 >类型。
- 一个项目（小部件类）可以有多个观察，一个观察仅与一个项目相关。
-用户可以偏好显示许多观察结果； 观察可能被许多用户首选（显示）。
更新
我们可以通过标记观察类型来简化用户对项目详细信息（观察）的订阅，例如高度、重量、宽度将被标记为：全部、尺寸、物理。其他一些标签包括：accounting_interest、tracking_specific 等。然后用户将仅订阅标签。标签（可以）形成一个层次结构，其中 ALL 位于顶部。
- 一个观察类型（身高、体重、颜色）可以有多个标签，一个标签属于多个观察类型。
- 每个标签可能有一个父标签，形成层次结构。
- 用户存储她通常监控的一组标签的首选项。
更新2
现在我们可以弄清楚谁是谁以及谁拥有什么。在此修改中，一个用户（现在是一个人）可以为多个组织工作（拥有多个兼职工作或合同）。 项目现在属于组织。登录的用户可以查看其工作的所有组织的所有项目。
Based on your description I sketched a simplified model and combined it with the observation pattern. This should enable you to track various item properties and user preferences for viewing them. Admittedly, the
Preferencetable may grow large, but data has to be stored somewhere anyway, and you may retrieve it using sql, which simplifies the business layer.- Organization and person are types of users.
Usertable has columns common to all users, whileOrganizationandPersontables have columns specific to each one.- A stock item (widget class) can be found at several sites (warehouses); a site stores many items.
- One item belongs to one user; a user can own many items.
- Measurement and trait are types of observations. Measurement is a numeric observation, like height. Trait is a descriptive observation, like color.
- An observation is of a specific type (height, weight, color), there can be many observations of the same type.
- One item (widget class) can have many observations, an observation relates to one item only.
- A user can prefer to display many observations; an observation may be preferred (to display) by many users.
UPDATE
We could simplify user's subscription to item details (observations) by tagging observation type, for example height, weight, width would be tagged with: all, dimensions, physical. Some other tags would be: accounting_interest, tracking_specific, etc. A user would then subscribe to tags only. Tags (could) form a hierarchy with ALL at the top.
- One observation type (height, weight, color) can have many tags, one tag belongs to many observation types.
- Each tag may have a parent tag forming a hierarchy.
- A user stores preferences for a set of tags that she usually monitors.
UPDATE 2
Now we can sort out who is who and who owns what. In this modification a user (now a person) can work for more than one organization (having several part-time jobs or contracts). An item belongs to a organization now. A logged-in user can see all items from all organization that she works for.
我对此的第一个快速想法是 - 如果这仅限于在仪表板上向特定组织“显示”特定字段，那么最好在应用程序端处理它。如果“标记”有任何其他用法，请澄清。
这是一个简单的方法 -
您可以将字段 [OrgDashboardFields] 存储在 Org 主表或 OrgItem 表中。这将是要在仪表板上显示的以逗号（','）分隔的字段列表。在运行时获取 [OrgDashboardFields] 字段并解析应用程序中的逗号分隔列表，并使仪表板网格相应地运行。
或者，如果有动态查询框架，则可以基于 [OrgDashboardFields] 字段创建一个动态 SQL 查询并获得纯粹组织特定的所需结果。
My first quick thot on this would be that - if this is just limited to 'showing' particular fields to particular Orgs on Dashboard then it is better to handle it on the App side. If there's any other usage of 'tagging' then pls clarify.
Here's a simple approach -
You can store a field [OrgDashboardFields] in the Org master table or the OrgItem table. This will be a comma (',') separated list of fields to be shown on the dashboard. At run-time fetch the [OrgDashboardFields] field and parse the comma separated list in the app and make the Dashboard Grid behave accordingly.
Or, if there's a dynamic-query framework then based on the [OrgDashboardFields] field you can create a dynamic SQL-query and get the desired result which is purely Org specific.