项的动态字段结构（部分）描述 - ADO / SQL / C＃ [英] Dynamic Field Structure for Item (Part) Description - ADO/SQL/C#

问题描述

我一直在寻找某种类库，它将拥有我正在寻找的那种DataBase工具，但我似乎无法找到任何东西。也许我不知道如何描述和搜索任务。在任何情况下，这都是我要找的：



ERP项目的动态字段结构（部分）数字：现代工程实践认为项目应该是唯一的非重要的零件号。以下是部件编号的简要介绍。



https：// en .wikipedia.org / wiki / Part_number [ ^ ]



因此，如果零件编号没有数据，您如何找到零件？答案是字段或属性。问题是没有现代的制造商使用所有具有相同字段结构的部件。如果项目主数据表中的第一个字段是主要部件类型，那么当您到达第二个或第三个字段（表中的行）时，字段标题（表中最左边的列）具有不同的字段含义。



例如，假设我们有两个项目......一个紧固件......和一个泵驱动轴。



泵轴字段可能如下：

字段1 =主要部分= SHAFT

字段2 =泵模型= 12GM

字段3 =叶轮连接= KEYED

字段4 =袖子=无

字段5 =材料= 316L



ERP系统中出现的文字描述如下：

SHAFT，12GM，KEYED，NONE，316L。这是通过使用逗号分隔的形式创建的，它只是简单地从行1,2,3,4等中提取描述。





现在螺栓



泵轴字段可能如下：

字段1 =主要部分= FASTENER

字段2 = FASTENER TYPE = SHCS

字段3 = THREAD = 3/4 UNC

字段4 =长度= 3L

字段5 =材料= 316L



ERP系统中出现的文字描述如下：

FASTENER，SHCS，3 / 4UNC ，3L，316L



问题是这两个项目需要驻留在同一个数据库中。一旦超过数据库表中的第1个字段，字段名称就会更改。对于轴，第二个字段用于泵模型。对于紧固件，第二个字段用于紧固件类型。



这是基于数据库（SQL）的项目识别中的常见问题，但我找不到优雅的解决方案。我知道答案与没有给第1行以外的字段赋予固定标题，并且有字段标题的辅助表有关，但看起来似乎有人会创建一个ADO.Net类库来处理这个问题。



实际上，我见过的每个制造商ERP系统仍然存在产品描述的不一致性。总是，同一部分多次进入：



轴，12GM，钥匙，无，316L

轴，钥匙，12GM，无，316L



等等。


乘以50,000个零件号......你就完整了一团糟，没有人能找到任何东西。

I have been searching in vain for some sort of class library which will have the sort of DataBase tools I am looking for, but I can not seem to find anything. Perhaps I do not know how to describe and search on the task. In any case, here is what I am looking for:

A Dynamic Field Based Structure for ERP Item (Part) Numbers: Modern Engineering Practice holds that items should have unique non-significant part numbers. Here is a brief primer on part numbering.

https://en.wikipedia.org/wiki/Part_number[^]

So, if the part number holds no data, how do you find the part? The answer is fields or attributes. The problem is that no modern mfg uses parts that all have the same field structure. If the first field in the item master data table is say "Major Part Type", by the time you get to the second or third field (row in the table), the field title (left most column in the table) has a different meaning.

For example, lets assume we have two items....a fastener...and a pump drive shaft.

The pump shaft fields might be the following:
Field 1 = Major part = SHAFT
Field 2 = Pump Model = 12GM
Field 3 = Impeller Connection = KEYED
Field 4 = Sleeve = NONE
Field 5 = Material = 316L

The text description which would appear in the ERP system would be the following:
SHAFT, 12GM, KEYED, NONE, 316L. This is created by using a comma delimited form which simply pulls the descriptions from rows 1,2,3,4 etc.


Now the bolt

The pump shaft fields might be the following:
Field 1 = Major part = FASTENER
Field 2 = FASTENER TYPE = SHCS
Field 3 = THREAD = 3/4 UNC
Field 4 = LENGTH = 3"L
Field 5 = Material = 316L

The text description which would appear in the ERP system would be the following:
FASTENER, SHCS, 3/4UNC, 3"L, 316L

The problem is these two items need to reside in the same data base. Once you get past the 1st field in the database table, the field designation changes. For the shaft, the second field is for the "pump model". For the fastener, the second field is for the "fastener type".

This is such a common problem in database (SQL) based item identification, but I can not find an elegant solution. I know that answer has something to do with not giving a fixed title to fields beyond row 1, and having a secondary table of field titles, but it sure seems like someone would have created a ADO.Net class library to handle this issue.

Virtually every mfg ERP system I have ever seen still suffers from inconsistency in how the item description is crafted. Invariably, the same part gets entered multiple times:

SHAFT, 12GM, KEYED, NONE, 316L
SHAFT, KEYED, 12GM, NONE, 316L

Etc.

Multiply this by 50,000 part numbers...and you have a complete mess and no one can find anything.

推荐答案

好吧。它是一个很大的主题，因此他们有许多不同的方法，每个方法都有自己的优点和缺点。



但他们通常都遵循这种方法。



具有自己的唯一ID和公共属性的工厂表。

属性的属性表。这些可以通过多种方式实现，但通常它们每个属性有一行，具有工厂的唯一ID和属性id（或者更明显的是属性详细信息本身）



在这周围你通常有属性详细信息的支持表，以及什么类型的工厂有什么类型的允许属性和属性数据类型等。



我想如果你问十个人你将得到十种不同的方法，最好的可能隐藏在你想要做的事情的细节中。

Well. Its a big subject and as such their are many different approaches each with their own pro and cons.

However they generally following this method.

A plant table with its own unique ID and common attributes.
Attributes table for the attributes. These can be achieved many ways but generally they have one row per attribute with the unique id of the plant and an attribute id (or more plainly the attribute details itself)

Around this you generally have supporting tables for attribute details, and what types of plant have what type of allowable attributes and the attribute data types etc.

I think if you ask ten people you will get ten different methods and the best is probably hidden in the minor details of what you are trying to do.

这篇关于项的动态字段结构（部分）描述 - ADO / SQL / C＃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！