2013-09-04 2 views
1

У меня около 50 типов продуктов в моей базе данных PostgreSQL 9.2.3.Одно поле со многими «точками» для каждого типа данных?

Некоторые из них являются делимыми, некоторые - нет.

Что делает вещи более сложными, так это то, что "volume" разных продуктов должны иметь различную точность.

Product type 1: allowed 8 decimal places. 
Product type 2: only integer values. 
Product type 3: 2 decimal places 
Product type 4: 2 decimal places 
Product type 5: 3 ---- || ------ 
Product type 6: 4 ---- || ------ 
Product type 7: 16 ---- || ----- 
Product type 8: integer values 
Product type 9: 4 decimal places 
Product type 10: 5 decimal places 
Product type 11: 12 decimal places 

Существует также "orders" стола, один для всех продуктов, где почти все столбцы являются же (пользователь, подрядчик, дата заказа, доставка цены и т.д.). Единственным исключением является - "volume".

Какой тип данных я должен использовать?

Я думал об использовании "numeric" поля для всех видов продукции + хранящей информации о точности для каждого типа продукта и преобразования значений в «заказы» зарегистрировать вид на требуемой точности, но не это приведет к сбоям непротиворечивости данных?

В этом решении нет способа проверить, например, целочисленное значение для «типа продукта 8» - целое число, я показываю его как целое. :(

Другой способ заключается в создании одного столбца на каждого типа данных, например, volume_int volume_num_2, volume_num_5, и т.д., которые на самом деле ужасно. :(

... и другое решение использовать наследование таблицы , как это:

orders <- volume is integer 
orders_product_1 (inherits orders) <- volume is numeric(24,8) 
orders_product_2 (inherits orders) <- volume is integer 
orders_product_3 (inherits orders) <- volume is numeric(20,2) 

... но создавая около 20 унаследовала таблицу кажется торжеством формы над содержанием ...

что бы быть лучшим решением Может быть, есть еще один способ решить проблема?

ответ

2

Использование NUMERIC с наибольшим масштабом и точностью вам нужно для любого из ценности.

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

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

Единственная альтернатива, которую я вижу, - это CREATE TYPE композитный тип, который имеет значение и единицы/прецизионность, хранящиеся рядом с ним. Это кажется тяжелым и будет больно работать.

1

Я бы сказал, с первым решением с числовым полем и таблицей с информацией о точности. В этом случае вы также можете изменить точность позже, если вам это нужно.
Или вы можете хранить все данные в виде целых чисел и хранить коэффициенты в некоторой таблице, и рассчитать поле как value * coefficient (который может быть 1, 0,01 и так далее)

Смежные вопросы