HSTORE Extension - Key-Value Store İçindir

Giriş
Açıklaması şöyle

hstore is a data type in PostgreSQL.It helps in implementing data in the form of key-value pairs for a single value. It is useful in scenarios, such as rows with many attributes that are rarely examined, or semi-structured data. Keys and values are simply text strings.

Açıklaması şöyle.

Interestingly, the most "holistic" approach to polyglot persistence appears to be being taken by PostgreSQL. In their database, you can have a Key-Value store, JSON documents and of course, normal relational tables and one can perform SQL between and within these different storage types.

Örnek - key alana göre sorgulama

detail sütunu bir HSTORE sütunu olsun ve key alanları department, city, manager_name olsun. Şöyle yaparız

CREATE TABLE employee (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255),
  detail HSTORE
);

INSER INTO employee (name,detail)
VALUES
 (
  'Divyanhs',
  '"department" => "Êngineering",
   "city" => "Delhi",
   "manager_name" => "Kuki"'
  ),
  ...
);

Bir key alana göre sorgulamak için şöyle yaparız

SELECT detail -> 'city' FROM employee;

Örnek

Şöyle yaparız. score sütünü HSTORE tipinden. İsim : sayı şeklinde bir JSON nesnesi yazarız

CREATE EXTENSION HSTORE;

CREATE TABLE hstore_example (score HSTORE);

INSERT INTO hstore_example VALUES('"Jason" => 100');
INSERT INTO hstore_example VALUES('"Jack" => 200');
INSERT INTO hstore_example VALUES('"Perry" => 150');

SELECT * FROM hstore_example WHERE score ? 'Jason'; //query rows

SELECT score -> 'Jason' AS score FROM hstore_example //query by key
WHERE score -> 'Jason' IS NOT NULL;

Sütun Tipleri - jsonb - Binary Formattadır, Whitespace İçermez

Giriş

Açıklaması şöyle. JSONB tipi 2014 yılında PostgreSQL 9.4 ile eklendi

In late 2014, PostgreSQL 9.4 introduced the JSONB datatype and most importantly improved the querying efficiency by adding indexing. 

The JSONB datatype stores JSON as a binary type. This introduced overhead in processing since there was a conversion involved, but it offered the ability to index the data using GIN/Full text-based indexing and included additional operators for easy querying.

Açıklaması şöyle. Binary formatta olduğu için whitespace saklamaz.

In Postgres, JSONB is a special kind of column that can store JSON in a format optimized for reads:

json Sütun Tipi ile Farkı

Açıklaması şöyle

Postgres support two forms of JSON types.

json — storing data as textual form in databases

jsonb — storing data as binary form in databases

Kısa Bir Uyarı

Her şeyi JSONB olarak saklamak iyi bir fikir gibi gelebilir. Ancak dikkatli olmak lazım çünkü daha sonra veriyi değiştirmek zor olabiliyor. Açıklaması şöyle.

PostgreSQL has json support – but you shouldn’t use it for the great majority of what you’re doing. This goes for hstore too, and the new jsonb type. These types are useful tools where they’re needed, but should not be your first choice when modelling your data in PostgreSQL, as it’ll make querying and manipulating it harder.

Constraint

Açıklaması şöyle. JSONB sütuna constraint koyulamaz.

Postgres cannot have primary and foreign key constraints on JSONB properties, but it can extract the properties into separate columns on inserts and updates, and those columns can have the constraints.

Index

JSONB sütuna GIN Index konulabilir.

Örnek
Whitespace saklamadığını görmek için şöyle yaparız.

SELECT '{"c":0,   "a":2,"a":1}'::json, '{"c":0,   "a":2,"a":1}'::jsonb;

          json          |        jsonb 
------------------------+--------------------- 
 {"c":0,   "a":2,"a":1} | {"a": 1, "c": 0} 
(1 row)

Select İşlemi
Açıklaması şöyle

The magical @> operator allows you to easily match a key-value pair or an object inside your JSON. It indeed makes easier to match things in JSON, although there are some things you should keep in mind:

- The operator @> behaves as equals comparisons if we search for an attribute
- The operator @> behaves as contains if we search for an array

Örnek

Attribute select için şöyle yaparız.

SELECT address->'city' FROM users WHERE address @> '{"zipcode": "94537"}'

Örnek

Attribute select için şöyle yaparız. Burada doc tablosundan silinen satırlar, child_table tablosuna ekleniyor.

INSERT INTO child_table SELECT doc FROM (
  DELETE FROM docs WHERE doc @> jsonb_build_object('type', 'doc_type') RETURNING doc
);

Array

Array contains için şöyle yaparız.

SELECT * FROM users WHERE address @> '{"entrances":[{"name": "backyard"}]}'

Insert İşlemi

Örnek
Şöyle yaparız. JSON '{...}' içine alınır. Key ve value değerleri çift tırnak içine alınır.

INSERT INTO users VALUES (1, 'First User', 'user1',  
'{"streetName": "Wayside Lane", "houseNumber": 3104, "zipcode": "94538"}');

Update İşlemi
JSONB_SET() metodu kullanılır. İlk parametresi sütun ismi, ikinci parametre key, üçüncü parametre yeni value değeridir.

-> operator attribute değerini text'e çevirmek için kullanılır.

Örnek
Şöyle yaparız.

UPDATE users SET address = jsonb_set(address, '{state}', '"California"')
  WHERE address->'state' = '"CA"';

JPA İle Kullanım

jsonb - JPA İle Kullanım yazısına taşıdım

Sütun Tipleri - Serial (Otomatik Sayı Üretir) - Kullanmayın

Giriş

Açıklaması şöyle. Yani SERIAL yerine IDENTITY kullanılırsa daha iyi

It is recommended to use IDENTITY instead since SERIAL has some weird behaviors.

Serial iki çeşit. Bunlar

1. SERIAL

2. BIGSERIAL

Bu sütunlara NOT NULL + PRIMARY KEY + UNIQUE gibi özellikler de atanabilir.

Diğer

Eğer serial veya bigserial yerine sequence kullanmak istersek şöyle yaparız

CREATE TABLE public.contacts
(
  contactid integer NOT NULL DEFAULT nextval('contacts_contactid_seq'::regclass),
  ...
);

1. SERIAL Sütun Tipi

Açıklaması şöyle

the keyword serial is PostgreSQL specific and it set up an auto-incrementing value and that is the typical way for the primary-key.

Açıklaması şöyle. 4 byte uzunluğundadır. Yani integer ile aynıdır.

Serial is just syntactic sugaring on top of an int column that takes its value from a sequence.

Açıklaması şöyle. Eğer transaction başarısız olsa bile serial numarası artmaya devam eder.

To avoid blocking concurrent transactions that obtain numbers from the same sequence, a nextval operation is never rolled back; that is, once a value has been fetched it is considered used, even if the transaction that did the nextval later aborts. This means that aborted transactions might leave unused "holes" in the sequence of assigned values.

Örnek
Şöyle yaparız.

create table testtable(
  id serial primary key,
  data integer not null
);

Şöyle yaparız.

insert into testtable ( data ) values ( 4 ), ( 5 ), ( 6 ), ( 7 );

Örnek

Şöyle yaparız

CREATE SCHEMA retail;
CREATE TABLE retail.orders_info (
  orderid SERIAL NOT NULL PRIMARY KEY,
  ...
);

Cache Parametresi
Açıklaması şöyle.

SERIAL columns are implemented using standard SQL sequences, which might generate out-of-order values when used by multiple concurrent sessions if the CACHE parameter is set to something more than 1

Daha detaylı açıklama şöyle.

Although multiple sessions are guaranteed to allocate distinct sequence values, the values might be generated out of sequence when all the sessions are considered. For example, with a cache setting of 10, session A might reserve values 1..10 and return nextval=1, then session B might reserve values 11..20 and return nextval=11 before session A has generated nextval=2. Thus, with a cache setting of one it is safe to assume that nextval values are generated sequentially; with a cache setting greater than one you should only assume that the nextval values are all distinct, not that they are generated purely sequentially.

2. BIGSERIAL Sütun Tipi
Örnek

Şöyle yaparız

CREATE TABLE foo (
  id BIGSERIAL PRIMARY KEY,
  ...
);

CREATE TABLE bar (
  foo_id BIGINT UNIQUE,
  ...
);

Örnek

Şöyle yaparız.

CREATE TABLE category
(
  id bigserial NOT NULL PRIMARY KEY,
  ...
)