资产管理数据库设计

发布于 2024-10-07 07:28:58 字数 470 浏览 0 评论 0原文

我目前正忙于实施基本的资产管理系统。不会很复杂。只是用来跟踪任何资产的名称、序列号、零件号和类型等。但是我遇到的问题是我也想合并书籍。不幸的是，书籍的结构与普通资产（例如标题、作者、isbn 代码等）有很大不同。

我希望社区能够提供一些他们认为最好的设计的见解。将书籍合并到资产管理中（如果是这样，数据库设计应该是什么样子），或者我应该简单地编写一个完全独立的、独立的图书馆模块（也许具有一些将书籍导出到资产管理系统的功能[带有更少/其他字段]）。

谢谢！

编辑：其他可能的方法是使捕获屏幕动态化，以便用户可以指定字段和值。然后可以将其作为 XML 存储在数据库中。但他并不是我首选的做法。

编辑2：我忘了提及，我非常受我可能使用的技术的约束。它们是 MySQL、GWT、Hibernate 和 Spring（无 Spring 事务）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

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

演出会有结束 2024-10-14 07:28:58

一种方法是使用文档样式的 no-sql 数据库（例如 Mongo）来存储资产。这样，每种不同类型的资产都可以轻松拥有自己的字段集，而不需要额外的表等。

基本上，我所想象的是类似于以下内容的伪代码：

class Asset
{
    int AssetNumber;
    int AssetType;
    string Description;
    // etc.
}
class BookAsset : Asset
{
    // book-specific fields
}
class ElectronicsAsset : Asset
{
    // electronics-specific fields
}
// etc.

因此额外的资产类型可以只是额外的派生类。然后，每个资产将作为其自己的独特文档写入文档数据库，并通过其资产编号（或根据其包含的字段进行搜索等）或名称或存储方式进行检索。

这将为您提供一个快速、简单的系统，并在您跟踪其他资产或有关现有资产的其他信息时提供您可能需要的灵活性。

根据您的编辑进行编辑：用户定义的字段应该可以正常工作。您可以将其设置为对象上的某种键/值字典，或者如果使用更动态的语言，甚至只需将字段添加到对象本身。 “基础资产”将由绝对必需的字段组成，其余字段可以更宽松地定义、有条件地必需、用户指定等。

One approach could be to use a document style no-sql database (such as Mongo) to store the assets. That way each different type of asset can easily have its own set of fields without requiring additional tables, etc.

Basically what I'm picturing is pseudo-code similar to:

class Asset
{
    int AssetNumber;
    int AssetType;
    string Description;
    // etc.
}
class BookAsset : Asset
{
    // book-specific fields
}
class ElectronicsAsset : Asset
{
    // electronics-specific fields
}
// etc.

So additional asset types can just be additional derived classes. Then each asset would be written to the document database as its own distinct document, and retrieved by its asset number (or searched for based on the fields it contains, etc.) or name or however it's stored.

This would give you a quick and easy system with the flexibility you'll likely want as you track additional assets, or additional information about existing assets.

Edit based on your edit: User-defined fields should work just fine with this. You can set it up as some kind of key/value dictionary on the object, or even just add the fields to the object itself if using a more dynamic language. The "base asset" would be composed of the fields which are absolutely required, the rest can be more loosely-defined, conditionally required, user-specified, etc.

回复收藏 0 原文

风月客 2024-10-14 07:28:58

将资产的一般概念与您希望能够合并的每种类型资产的具体细节分开是有意义的。通常，这将采用主资产表的形式，其中针对您希望包含的每种不同类型的资产（即书籍、硬件、家具）使用不同的表。结构可能如下所示：

Asset(AssetId, Description, Comments)

HardwareAsset(HardwareAssetId, AssetId, SerialNumber, ...)

BookAsset(BookAssetId, AssetId, ISBN, Publisher, Author, ...)

其中 HardwareAsset 和 BookAsset 中的 AssetId 是 Asset 表的外键。这样，您就可以跟踪不同的资产，并在需要时将它们分组在一起。

编辑：或者，您可以创建一个键值表来存储各个对象的值，它可能如下所示：

AssetValue(AssetValueId, AssetId, Key, Value)

但是，这是一个繁琐的解决方案，虽然仍然提供可搜索字段，但会很快使您的数据库膨胀。为了缓解这个问题，您可以根据您的要求限制字段大小。我不建议在单个字段中序列化字典，因为这会使您的数据库更加膨胀。

It makes sense to separate the general notion of an asset from the specifics of each type of asset you want to be able to incorporate. Typically, this would take the form of a master Asset table, with different tables for each distinct type of asset you wish to include, i.e. Book, Hardware, Furniture. The structure might look like this:

Asset(AssetId, Description, Comments)

HardwareAsset(HardwareAssetId, AssetId, SerialNumber, ...)

BookAsset(BookAssetId, AssetId, ISBN, Publisher, Author, ...)

Where AssetId in both HardwareAsset and BookAsset is a foreign key to the Asset table. That way, you can keep track of different assets and group them together when it should matter.

EDIT: Alternatively, you can create a key - value table to store values for individual objects, which could look like this:

AssetValue(AssetValueId, AssetId, Key, Value)

However, this is a cumbersome solution that, while still providing for searchable fields, will quickly bloat your database. To mitigate the problem you can limit the field size depending on your requirements. I do not suggest serializing the dictionary inside a single field, as this will bloat your database even more.

回复收藏 0 原文