ArrayList примитивных типов в Hibernate - PullRequest
Новая
       13

ArrayList примитивных типов в Hibernate

2 голосов
/ 27 мая 2010

У меня есть вопрос, касающийся ArrayList из целых чисел или примитивных типов в целом. Предположим, я разрабатываю POS-программу, и у каждого продукта может быть несколько цен.

Давайте предположим, что я могу представить значение цены с int с, а в классе Product у меня есть поле ArrayList<Integer> prices. Какой лучший способ сопоставить это с Hibernate?

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

С другой стороны, я мог бы объединить все цены в String и сохранить его в виде поля в таблице products, например, с ценами, разделенными точками с запятой. Таким образом, я сохраняю одну таблицу и будущее select, но это не совсем нормально.

Что здесь лучше всего делать?

Ответы [ 2 ]

8 голосов
/ 27 мая 2010

Давайте забудем образец здесь (который может быть не лучшим). В Hibernate вы можете отобразить коллекцию базовых типов или встраиваемых объектов с помощью аннотации @CollectionOfElements (и дополнительно @IndexColumn для упорядоченных коллекций): 

@Entity
public class Product {
    @Id @GeneratedValue
    private Long id;

    @CollectionOfElements @IndexColumn(name="price_index")
    private List<Integer> prices = new ArrayList<Integer>();

    ...
}

Семантически это близко к @OneToMany, за исключением того, что элементы коллекции не являются сущностями, у них нет свойства id, а их жизненный цикл полностью зависит от объекта-владельца.

С точки зрения базы данных это приведет к таблице для продукта и к таблице цен: 

create table Product (id bigint not null, primary key (id))
create table Product_prices (Product_id bigint not null, element integer, price_index integer not null, primary key (Product_id, price_index))
alter table Prodcut_prices add constraint FK9D26D06FB343359D foreign key (Product_id) references Product

В JPA 2.0 эта аннотация стандартизирована, поэтому предпочитайте новую аннотацию @ElementCollection, если вы используете JPA 2.0.

С учетом вышесказанного, для конкретного случая Product and Price то, что @duffymo говорит, очень верно, и, вероятно, их не следует реализовывать с использованием упомянутых аннотаций.

5 голосов
/ 27 мая 2010

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

Нет, это не реляционно. Это нарушает правила для первой нормальной формы.

Я не понимаю, почему вы беспокоитесь о сохранении таблицы и SELECT. В худшем случае это преждевременная оптимизация.

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

Я бы порекомендовал таблицу Product без информации о ценах или скидках.

Звучит так, как если бы в Price указана дата вступления в силу, между товарами и ценами была бы взаимосвязь "многие ко многим", поэтому у вас также будет таблица Product_Price JOIN.

...