Asset Management Database Design - mysql

Question

I am currently busy implementing a basic Asset Management System. It will not be very complicated. Simply something to keep track of any asset with it's name, serial number, parts number and type etc. The problem I have however, is that I want to incorporate books as well. Unfortunately, books have a very different structure than normal assets (for example title, authors, isbn codes etc.).
I would like some insight from the community as to what design they think is best. Incorporate books in asset management (and if so, how should the database design look), or should I simply write a completely seperate, independant Library module (maybe with some functionality to export a book to the Asset Management System [with fewer / other fields]).
Thanks!
EDIT: Something else that is possible is to make the capture screen dynamic, so the user can specify the fields and the values. This can then be stored in as XML in the database. But his would not be my preferred way of doing it.
EDIT 2: I forgot to mention, I am very bound by the technologies that I may use. These are MySQL, GWT, Hibernate and Spring (no Spring transactions).

Answer 1

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.

Answer 2

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.

Answer 3

From the technology constraints I would suggest keeping the modules separate.

Answer 4

Yes on the main table you can flag what type of asset it is. So if it
is a book asset them a foreign key can link it to the book items. this
way you will not waste space on those assets that do not have these items.