29 Ocak 2019 Salı

Sütun Tipleri - VARCHAR - Variable Length Standart Sütun Tipi

Giriş
Hibernate ile DDL üretiyorsak değişken tipimiz String ise varchar(255) olarak sütun yaratılır.

CHARACTER VARYING
Açıklaması şöyle. Yani VARCHAR ve CHARACTER VARYING aynı şey
In PostgreSQL, VARCHAR is an alias for CHARACTER VARYING. This means that you can use either CHARACTER VARYING or VARCHAR to define a column that stores variable-length character strings. However, CHARACTER VARYING is the preferred term in PostgreSQL.
VARCHAR Tipe LENGTH Verirsek
Açıklaması şöyle. Yani en fazla 10 milyon küsur bir sayı verilebilir
The limit for varchar when you specify a length limit (type modifier) is 10485760
Görmek için şöyle yaparız. Burada LENGTH  olarak 10 milyar veriliyor ve hata alıyoruz
SELECT 'x'::varchar(1000000000);
ERROR:  length for type varchar cannot exceed 10485760
VARCHAR Tipe LENGTH Vermezsek
Bir yazıda şöyle bir cümle geçiyordu. Diğer veri tabanlarında LENGTH vermezsek varsayılan değer 1.
In SQL, if you declare a string in any of the four formats, CHAR, NCHAR, VARCHAR, or NVARCHAR, without specifying its length, the string is given the length of one character. If you coerce a string using CAST or CONVERT and make the same mistake, it gets a length of thirty characters. Why one and thirty? Historical reasons only, but other RDBMSs react in similar ways.
Ancak PostgreSQL açısından durum farklı. Açıklaması şöyle. Yani length vermezsek, TEXT gibi davranır.
If you do not specify the n integer for the varchar data type, it behaves like the text data type. The performance of the varchar (without n) and text are the same.
CHAR vs VARCHAR 
Başka veri tabanlarında CHAR ve VARCHAR arasında performans farkı olabiliyor. Örneğin SQL Server için açıklama şöyle
Because of the fixed field lengths, data is pulled straight from the column without doing any data manipulation and index lookups against varchar are slower than that of char fields. CHAR is better than VARCHAR performance wise, however, it takes unnecessary memory space when the data does not have a fixed-length. So in cases where disk size is not an issue, it is recommended to use CHAR.
Ancak PostgreSQL için performans farkı yok. Açıklaması şöyle
CHAR and VARCHAR are implemented exactly the same in Postgres (and Oracle). There is no difference in speed when using those data types.

27 Ocak 2019 Pazar

Sütun Tipleri - Text - Variable Length Standart Olmayan Sütun Tipi

Giriş
PostgreSQL'de metin saklamak için şu tipler kullanılabilir.
- char(n)
- varchar(n)
- varchar
- text

- Bu yazıyla ilgili olarak Sütun Tipleri - varchar yazısına da bakabilirsiniz.
- text tipi standart SQL tipi değildir.

Altta Kullanılan Tip
Açıklaması şöyle
Regardless of whether we choose char, varchar or text , the underlying structure PostgreSQL uses is varlena
varlena için açıklama şöyle
Note: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) it has performance advantages in some other database systems, PostgreSQL has no such advantage.  In fact, character(n) it is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

1. Fixed Length Alanlar
char(n) ve varchar(n) belirtilen uzunluğu geçemezler yani fixed length kabul edilirler. char(n) belirtilen uzunluktan daha kısa değerleri blank karakter ile doldurur yani padler.  Fixed Length Alanlar mümkünse tercih edilmemeli. Açıklaması şöyle
A common mistake is to choose a restrictive data type that doesn’t scale in the future. For example: A column containing some string can be of 3 types in PostgreSQL - varchar(n), character(n), text. When choosing the former two, you are restricted to the number of characters you can use. Choosing text type for data is usually harmless and is scalable to accommodate more characters in the future. And if need be, you can add check constraints to restrict data input.
2. Variable Length Alanlar
varchar ve text ise bir uzunluğa sahip değildirler yani variable length kabul edilirler. Açıklaması şöyle.
If you do not specify the n integer for the varchar data type, it behaves like the text data type. The performance of the varchar (without n) and text are the same.
text'in tercih edilmesinin sebebi isminin daha ayırd edici olması. Açıklaması şöyle.
text – for me a winner – over (n) data types because it lacks their problems, and over varchar – because it has distinct name

3. En Büyük Text Alanı
Açıklaması şöyle.
In any case, the longest possible character string that can be stored is about 1 GB.
Örnek
Şöyle yaparız.
CREATE TABLE category
(
  name text NOT NULL,
  ...
)
Örnek
Şöyle yaparız.
create table mytable (
    id INTEGER PRIMARY KEY,
    data TEXT
);
INSERT INTO mytable VALUES
    (0, 'a'),
    (1, 'b'),
    (2, 'c'),
    (3, 'd'),
    (4, 'e'),
    (5, 'f'),
    (6, 'g'),
    (7, 'h'),
    (8, 'i'),
    (9, 'j');

ORDER BY + LIMIT + OFFSET

ORDER BY Nedir?
Order by kullanılmazsa veri tabanı sonucu istediği şekilde sıralayarak döndürür. Açıklaması şöyle.
After a query has produced an output table (after the select list has been processed) it can optionally be sorted. If sorting is not chosen, the rows will be returned in an unspecified order. The actual order in that case will depend on the scan and join plan types and the order on disk, but it must not be relied on. A particular output ordering can only be guaranteed if the sort step is explicitly chosen.
Bir başka açıklama şöyle
If ORDER BY is not given, the rows are returned in whatever order the system finds fastest to produce.
LIMIT Nedir
Açıklaması şöyle
To limit the result, Postgres uses limit ... (SQL-server uses TOP keyword)
Örnek
Şöyle yaparız.
SELECT rental_duration FROM films
  ORDER BY length
  LIMIT 5 OFFSET 498 AS A

21 Ocak 2019 Pazartesi

Crosstab

Giriş
pivot tablo oluşturmak içindir. Açıklaması şöyle.
Unless you add a WHERE clause to ensure not more than N values are returned by the inner query, more values will need to be added as your database grows.
Örnek
Elimizde şöyle bir kod olsun.
create table reader_event
(
   reader_event_id serial,
   reader_name text,
   event_type varchar(25),
   event_date timestamp,
   metric_key text,
   metric_value bigint
)
Şöyle yaparız.
reader_name ilk sütun olur.
İkinci sütun metric_key = metric_value1 olan satırladır. ve değeri metric_value değeridir.
Üçüncü sütun metric_key = metric_value2 olan satırladır. ve değeri metric_value değeridir.
Dödüncü sütun metric_key = metric_value3 olan satırladır. ve değeri metric_value değeridir.
select * from crosstab('select b.reader_name, b.metric_key, b.metric_value from b') 
AS Final Result (reader_name text,
                 metric_value1 bigint,
                 metric_value2 bigint,
                 metric_value3 bigint)