Сохранение любого объекта в реляционной базе данных - PullRequest
Новая
       46

Сохранение любого объекта в реляционной базе данных

2 голосов
/ 29 февраля 2012

Это может показаться немного причудливым, но есть ли какой-либо шаблон или что-то для хранения любого типа Объекта в Реляционной базе данных (не nosql) оптимальным образом?

например, ни в одном из оптимальныхпуть: 

class Person{
    string FirstName {get;set;}
    string LastName {get;set;}
} 

class Product{
    string Name {get;set;}
    decimal Price {get;set;}
}

и в базе данных: 

CREATE TABLE Data
   (Id int PRIMARY KEY, 
    TypeName nvarchar(50), 
    PropertyName nvarchar(50), 
    PropertyValue binary)

, тогда записи сохраняются в базе данных следующим образом: 

1    Person    FirstName   Jalal

2    Person    LastName    A.R

3    Product   Name        Apple

4    Product   Price       2

Ответы [ 4 ]

3 голосов
/ 29 февраля 2012

То, что вы описываете, по сути является таблицей Entity-Attribute-Value .

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

Неправильное использование, это классический пример эффект внутренней платформы .

2 голосов
/ 29 февраля 2012

Вы можете сериализовать свой объект в XML и сохранить его в базе данных.SQL Server имеет специализированный тип XML, который даже позволяет запрашивать содержимое.

Это не оптимальное решение, но оно будет делать то, что вам нужно.

0 голосов
/ 29 февраля 2012

То, что вы описали, не является реляционным подходом, поэтому я не понимаю, почему вы хотите использовать реляционную базу данных.Вы складываете каждый предмет в один большой стол.Вы полностью теряете возможность определять отношения между таблицами или выполнять реляционные операции (например, «найти всех покупателей, которые купили яблоко в этом месяце»).

0 голосов
/ 29 февраля 2012

Не уверен, почему вы сделали бы это едва ли оптимальным.Если вы ищете человека, вам нужно отсканировать таблицу или выполнить поиск индекса по строковому значению, а затем отфильтровать по первичному ключу.

ORM будет намного лучше - nHibernate или Entity Framework (EF) будут сопоставлять каждый класск таблице и автоматически генерирует первичные ключи и т. д., и вы можете выразить объекты как дочерние объекты и т. д.

EF также может сначала делать код - это означает, что вы просто пишете классы, и он создает базу данных и автоматически сопоставляет их всеup (возможно, nHibernate делает то же самое, просто я не знаю продукт)

...