Re: Composite type storage overhead

Поиск
Список
Период
Сортировка
От Thomas Kellerer
Тема Re: Composite type storage overhead
Дата
Msg-id 2d715b05-dce4-9aec-e01b-cb3213386f5c@gmx.net
обсуждение исходный текст
Ответ на Re: Composite type storage overhead  (Laiszner Tamás <t.laiszner@outlook.com>)
Ответы Re: Composite type storage overhead  (Laiszner Tamás <t.laiszner@outlook.com>)
Список pgsql-general
> 3. The value is logically defined as a 128-bit integer, that is in
> itself a compound value split into a few "bit groups". Extracting
> these parts can be done by simple (and supposedly efficient) bitwise
> operators when stored as integer, but becomes much more cumbersome
> with UUID, I guess.

This is usually a bad idea. 

Putting logic into the primary key value and merging different types of information in a single column is typically not
sucha good idea. 
 
(And it violates first normal form to begin with) 

I would strongly recommend to revisit this idea, and e.g. think about a multi-column primary key instead. Where each of
these"groups" are stored in a separate column where the actual (business) value can be retrieved without any
bitshiftingor similar operations. 
 

Thomas





В списке pgsql-general по дате отправления:

Предыдущее
От: Maurice Aubrey
Дата:
Сообщение: Re: jsonb_set() strictness considered harmful to data
Следующее
От: Laiszner Tamás
Дата:
Сообщение: Re: Composite type storage overhead