Разработка базы данных управления активами

Question

В настоящее время я занят внедрением базовой системы управления активами. Это будет не очень сложно. Просто что-то, чтобы отслеживать любой актив с его именем, серийным номером, номером детали и типом и т. Д. Однако у меня проблема в том, что я хочу включить книги. К сожалению, книги имеют совершенно иную структуру, чем обычные активы (например, название, авторы, коды ISBN и т. Д.).

Я хотел бы получить от сообщества представление о том, какой дизайн они считают лучшим. Включите книги в управление активами (и если да, то как должен выглядеть дизайн базы данных), или я должен просто написать полностью отдельный, независимый модуль библиотеки (возможно, с некоторыми функциями для экспорта книги в систему управления активами [с меньшим количеством других полей) ]).

Спасибо!

РЕДАКТИРОВАТЬ: Возможно еще что-то сделать динамический экран захвата, так что пользователь может указать поля и значения. Это может быть сохранено в виде XML в базе данных. Но он не был бы моим предпочтительным способом сделать это.

РЕДАКТИРОВАТЬ 2: Я забыл упомянуть, я очень привязан к технологиям, которые я могу использовать. Это MySQL, GWT, Hibernate и Spring ( без транзакций Spring ).

Answer 1

Да, на главной таблице вы можете указать тип актива.Поэтому, если это актив книги, внешний ключ может связать его с элементами книги.Таким образом, вы не будете тратить пространство на те активы, которые не имеют этих предметов.

Answer 2

Имеет смысл отделить общее понятие актива от специфики каждого типа актива, который вы хотите включить. Как правило, это принимает форму основной таблицы активов с различными таблицами для каждого отдельного типа актива, который вы хотите включить, например, «Книга», «Оборудование», «Мебель». Структура может выглядеть так:

Asset(AssetId, Description, Comments)

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

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

Где AssetId в HardwareAsset и BookAsset - это внешний ключ к таблице Asset. Таким образом, вы можете отслеживать различные активы и группировать их вместе, когда это должно иметь значение.

---

РЕДАКТИРОВАТЬ: Кроме того, вы можете создать таблицу ключ-значение для хранения значений для отдельных объектов, которые могут выглядеть следующим образом:

AssetValue(AssetValueId, AssetId, Key, Value)

Однако это громоздкое решение, которое, хотя и предоставляет поля для поиска, быстро раздувает вашу базу данных. Чтобы смягчить проблему, вы можете ограничить размер поля в зависимости от ваших требований. Я не предлагаю сериализовать словарь внутри одного поля, так как это приведет к еще большему увеличению вашей базы данных.

Answer 3

Из-за технологических ограничений я бы предложил хранить модули отдельно.

Answer 4

Одним из подходов может быть использование базы данных 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.

Таким образом, дополнительные типы активов могут быть просто дополнительными производными классами.Затем каждый актив будет записан в базу данных документов в виде отдельного отдельного документа и извлечен по номеру актива (или будет выполнен поиск по полям, которые он содержит и т. Д.) Или по имени или как он будет сохранен.

даст вам быструю и простую систему с гибкостью, которая вам, вероятно, понадобится при отслеживании дополнительных активов или дополнительной информации о существующих активах.

Редактирование на основе ваших изменений: Определяется пользователемполя должны работать просто отлично с этим.Вы можете настроить его как своего рода словарь ключ / значение для объекта или даже просто добавить поля к самому объекту, если используете более динамичный язык.«Базовый актив» будет состоять из полей, которые являются абсолютно обязательными, остальные могут быть более свободно определены, условно обязательны, определены пользователем и т. Д.