Update Turkish FAQ, Devrim GUNDUZ
This commit is contained in:
Bruce Momjian
parent
fee9629cf1
commit
887a136572
309
doc/FAQ_turkish
309
doc/FAQ_turkish
|
|
@ -1,11 +1,11 @@
|
|||
PostgreSQL için Sıkça Sorulan Sorular (SSS)
|
||||
|
||||
Son güncelleme : 19.05.2003 Cuma 05:03
|
||||
Son güncelleme : 23 Şubat 2004 Pazartesi - 13:34:26
|
||||
|
||||
Bruce Momjian (pgman@candle.pha.pa.us)
|
||||
Çeviren : Devrim GÜNDÜZ (devrim@gunduz.org), Nicolai Tufar (ntufar@yahoo.com), Volkan Yazýcý (volkany@celiknet.com)
|
||||
Çeviren : Devrim GÜNDÜZ (devrim@gunduz.org), Nicolai Tufar (ntufar@yahoo.com), Volkan YAZICI (vyazici@phreaker.net)
|
||||
|
||||
Bu belgenin en güncel hali, http://www.gunduz.org/seminer/pg/FAQ_turkish ve
|
||||
Bu belgenin en güncel hali, http://www.gunduz.org/seminer/pg/FAQ_turkish.html ve
|
||||
http://www.PostgreSQL.org/docs/faq-turkish.html
|
||||
adreslerinde gorülebilir.
|
||||
|
||||
|
|
@ -60,7 +60,7 @@
|
|||
|
||||
4.1) Binary cursor ve normal cursor arasındaki fark nedir?
|
||||
4.2) Sorgunun sadece ilk birkaç satırını nasıl SELECT edebilirim?
|
||||
4.3) psql'in içinde gördüðüm tablolarýn ya da diðer þeylerin listesini nasil alabilirim?
|
||||
4.3) psql'in içinde gördüğüm tabloların ya da diğer şeylerin listesini nasıl alabilirim?
|
||||
4.4) Bir tablodan bir kolonu nasıl kaldırabilirim?
|
||||
4.5) Bir satır, tablo ve veritabanı icin en fazla büyüklük nedir?
|
||||
4.6) Tipik bir metin dosyasındaki veriyi saklamak için ne kadar disk alanı gereklidir?
|
||||
|
|
@ -69,8 +69,8 @@
|
|||
4.9) Query-optimizer in sorgularımı nasıl değerlendirdigini, işleme soktuğunu nasıl görebilirim?
|
||||
4.10) R-tree index nedir?
|
||||
4.11) Genetic Query Optimizer nedir?
|
||||
4.12) Düzenli ifade (Regular Expression) aramalarýný ve büyük/küçük harfe duyarsýz aramalarý nasil yapabilirim?
|
||||
Bu büyük(küçük harfe duyarlý aramalar için indeksi nasil kullanabilirim?
|
||||
4.12) Düzenli ifade (Regular Expression) aramalarını ve büyük/küçük harfe duyarsız aramaları nasıl yapabilirim?
|
||||
Bu büyük(küçük harfe duyarlı aramalar için indeksi nasıl kullanabilirim?
|
||||
|
||||
4.13) Bir sorguda, bir alanın "NULL" olduğunu nasıl ortaya çıkarabilirim?
|
||||
4.14) Çesitli karakter tipleri arasındaki farklar nelerdir?
|
||||
|
|
@ -89,7 +89,7 @@
|
|||
4.23) Outer join işlemini nasıl yapabilirim?
|
||||
4.24) Aynı anda birden fazla veritabanında nasıl işlem yapabilirim?
|
||||
4.25) Bir fonksiyondan nasıl çoklu satır ya da kolon döndürebilirim?
|
||||
4.26) Neden Pl/PgSQL fonksiyonlarý içinden güvenli bir þekilde tablo yaratma/kaldýrma iþlemlerini yapamýyoruz?
|
||||
4.26) Neden PL/pgSQL fonksiyonları içinden güvenli bir şekilde tablo yaratma/kaldırma işlemlerini yapamıyoruz?
|
||||
4.27) Hangi replikasyon seçenekleri bulunmaktadır?
|
||||
4.28) Hangi şifreleme seçenekleri bulunmaktadır?
|
||||
|
||||
|
|
@ -169,14 +169,14 @@
|
|||
libpq C kütüphanesini, psql ve diger arabirimleri ve binary dosyaları, MS
|
||||
Windows ortamlarında çalısması için derlemeniz mümkündür. Bu örnekte istemcide
|
||||
MS Windows çalısıyor ve desteklenen Unix platformlarından birinde çalısan PostgreSQL
|
||||
sunucuna TCP/IP ile baglanmaktadýr. Daðýtým içindeki win31.mak dosyasý ile,
|
||||
sunucuna TCP/IP ile baglanmaktadır. Dağıtım içindeki win32.mak dosyası ile,
|
||||
Win32 libpg kütüphanesi ve psql yaratabilirsiniz. PostgreSQL aynı zamanda ODBC
|
||||
istemcileri ile haberlesebilmektedir.
|
||||
|
||||
Sunucu
|
||||
|
||||
Veritabaný sunuucsu Cygwin kullanarak Windows NT, 2K ya da XP üzerinde calistirilabilir.
|
||||
Dagýtým içindeki pgsql/doc/FAQ_MSWýN dosyasýný ya da web sitemizdeki MS Windows FAQ'u
|
||||
Veritabanı sunucusu Cygwin kullanarak Windows NT, 2K ya da XP üzerinde çalıştırılabilir.
|
||||
Dağıtım içindeki pgsql/doc/FAQ_MSWıN dosyasını ya da web sitemizdeki MS Windows FAQ'u
|
||||
inceleyebilirsiniz.
|
||||
|
||||
Doğal Windows NT/2000/XP portu için şu anda çalışmalar devam etmektedir. Windows sürümü
|
||||
|
|
@ -185,15 +185,15 @@
|
|||
|
||||
Ayrıca, http://forge.novell.com adresinde Novell Netware 6 portu bulunmaktadır.
|
||||
|
||||
1.5) PostgreSQL'in nereden indirebilirim?
|
||||
1.5) PostgreSQL'i nereden indirebilirim?
|
||||
|
||||
PostgreSQL için ana anonim ftp sitesi ftp://ftp.PostgreSQL.org/pub ' dur.
|
||||
Yansılar için, ana web sayfamıza bakabilirsiniz.
|
||||
|
||||
1.6) Desteği nereden alabilirim?
|
||||
|
||||
Ana e-posta listesi : pgsql-general@PostgreSQL.org. PostgreSQL konusundaki tartýsmalara
|
||||
açýktýr. Üye olmak için, asagýdaki satýrlarý e-postanizin body kýsmýna (konu kýsmýna degil)
|
||||
Ana e-posta listesi : pgsql-general@PostgreSQL.org. PostgreSQL konusundaki tartışmalara
|
||||
açıktır. Üye olmak için, asağıdaki satırları e-postanızın gövde kısmına (konu kısmına değil)
|
||||
yazıp, pgsql-general-request@PostgreSQL.org adresine gönderin:
|
||||
|
||||
subscribe
|
||||
|
|
@ -207,30 +207,30 @@
|
|||
|
||||
yazan bir e-posta atmanız yeterli olacaktır.
|
||||
|
||||
Digest postalar, ana liste 30k civarýnda e-postaya ulastiginda üyelere gönderilmektedir.
|
||||
Digest postalar, ana liste 30k civarında e-postaya ulastığında üyelere gönderilmektedir.
|
||||
|
||||
Buglar için bir e-posta listesi bulunmaktadır. Bu listeye üye olmak için,
|
||||
email to pgsql-bugs-request@PostgreSQL.org adresine, body kýsmýnda
|
||||
pgsql-bugs-request@PostgreSQL.org adresine, body kısmında
|
||||
|
||||
subscribe
|
||||
end
|
||||
|
||||
yazan bir e-posta atmanız yeterli olacaktır.
|
||||
|
||||
Ayný zamanda, gelistiriciler için tartýsma listesi bulunmaktadýr. Bu listeye üye olmak
|
||||
için, pgsql-hackers-request@PostgreSQL.org adresine, body kýsmýnda
|
||||
Aynı zamanda, geliştiriciler için tartışma listesi bulunmaktadır. Bu listeye üye olmak
|
||||
için, pgsql-hackers-request@PostgreSQL.org adresine, gövde kısmında
|
||||
|
||||
subscribe
|
||||
end
|
||||
|
||||
yazan bir e-posta atmanız yeterli olacaktır.
|
||||
|
||||
Bunun dýsýndaki e-posta listelerine ve PostgreSQL hakkýnda bilgiye, PostgreSQL WWW
|
||||
ana sayfasýndan ulasabilirsiniz:
|
||||
Bunların dışındaki e-posta listelerine ve PostgreSQL hakkında bilgiye, PostgreSQL WWW
|
||||
ana sayfasından ulaşabilirsiniz:
|
||||
|
||||
http://www.PostgreSQL.org
|
||||
|
||||
Ayný zamanda, EFNet üzerinde, #PostgreSQL adlý bir ýRC kanalý bulunmaktadýr. Bunun için,
|
||||
Aynı zamanda, EFNet ve OpenProjects üzerinde, #PostgreSQL adlı bir IRC kanalı bulunmaktadır. Bunun için,
|
||||
irc -c '#PostgreSQL' "$USER" irc.phoenix.net Unix komutunu kullanabilirsiniz.
|
||||
|
||||
Ticari destek veren firmaların listesine,
|
||||
|
|
@ -318,7 +318,7 @@
|
|||
PostgreSQL mevcut büyük ticari veritabanlarinin, transaction, subselect,
|
||||
trigger, view, foreign key referential integrity ve sophisticated locking gibi
|
||||
tüm özelliklerine sahiptir. Onlarin sahip olmadiklari, kullanici-tanimli tipler
|
||||
(user-defined types), rules, inheritance ve lock cakýsmalarini düsürmek icin
|
||||
(user-defined types), rules, inheritance ve lock cakışmalarını düşürmek için
|
||||
multi-version uyumluluk özellikleri bulunmaktadir.
|
||||
|
||||
Performans (Başarım)
|
||||
|
|
@ -460,7 +460,7 @@
|
|||
ve $PGDATA_pg_hba.conf dosyasını düzenleyerek host-based authentication'a
|
||||
olanak vermezseniz, baglantı yapamayacaklardır.
|
||||
|
||||
3.6) Veritabani motorunu daha iyi basarim icin nasil ayarlayabilirim?
|
||||
3.6) Veritabani motorunu daha iyi basarim icin nasıl ayarlayabilirim?
|
||||
|
||||
Indexler sorguları hızlandırabilir. EXPLAIN komutu, PostgreSQL'in sorgunuzu nasıl
|
||||
yorumladığını ve hangi indexleri kullandigini görmenize izin verir.
|
||||
|
|
@ -577,17 +577,15 @@
|
|||
|
||||
DECLARE yardım sayfasina bakiniz.
|
||||
|
||||
4.2) Sorgunun sadece ilk birkaç satýrýný nasil SELECT edebilirim?
|
||||
4.2) Sorgunun sadece ilk birkaç satırını nasıl SELECT edebilirim?
|
||||
|
||||
FETCH yardım sayfasina bakiniz, aya da SELECT ... LIMIT.... kullanınız.
|
||||
|
||||
The entire query may have to be evaluated, even if you only want the
|
||||
first few rows. Consider a query that has an ORDER BY. ýf there is an
|
||||
index that matches the ORDER BY, PostgreSQL may be able to evaluate
|
||||
only the first few records requested, or the entire query may have to
|
||||
be evaluated until the desired rows have been generated.
|
||||
İlk birkaç satırı almak isteseniz bile, tüm sorgu değerlendirilmek durumunda kalınabilir. ORDER BY içeren bir
|
||||
sorgu düşünün. Eğer ORDER BY işe eşleşen bir index varsa, PostgreSQL istenen ilk birkaç satırı işleyebilir, ya da
|
||||
tüm sorgu istenen satırlar üretilene kadar işlenebilir.
|
||||
|
||||
4.3) psql'in içinde gördügüm tablolarin ya da diger seylerin listesini nasil alabilirim?
|
||||
4.3) psql'in içinde gördügüm tablolarin ya da diger seylerin listesini nasıl alabilirim?
|
||||
|
||||
pgsql/src/bin/psql/describe.c içindeki psql kaynak kodunu okuyabilirsiniz. Bu kod,
|
||||
psql'in \ ile baslayan komutlarının çıktısını olusturan SQL komutlarini içerir. Aynı
|
||||
|
|
@ -612,8 +610,8 @@
|
|||
|
||||
Sınırlar:
|
||||
|
||||
Veritabani icin en fazla büyüklük nedir? Sýnýrsýz (4 TB'lýk veritabaný bulunmaktadýr)
|
||||
Bir tablo icin en fazla büyüklük nedir? 16 TB
|
||||
Veritabani icin en fazla büyüklük nedir? Sınırsız (32 TB'lık veritabanı bulunmaktadır)
|
||||
Bir tablo icin en fazla büyüklük nedir? 32 TB
|
||||
Bir satır için en fazla büyüklük nedir? 1.6 TB
|
||||
Bir alan için en fazla büyüklük nedir? 1 GB
|
||||
Tabloda en fazla satır sayısı kaçtır? Sınırsız
|
||||
|
|
@ -664,7 +662,7 @@
|
|||
|
||||
NULL değerler bitmapler içinde tutulur; dolayısıyla çok az yer kaplarlar.
|
||||
|
||||
4.7) Veritabanýnda hangi tablo ya da indexlerin tanýmlandýgýný nasil görebilirim?
|
||||
4.7) Veritabanında hangi tablo ya da indexlerin tanımlandıgını nasıl görebilirim?
|
||||
|
||||
psql, bu tür bilgileri göstermek için, \ ile başlayan bir çok komut sunmaktadır.
|
||||
\? komutu ile bu komutları görebilirsiniz. Ayrıca, bunları açıklayan ve pg_ ile başlayan
|
||||
|
|
@ -675,69 +673,67 @@
|
|||
sistem dosyalarindan bilgiyi almak için gereksinim duyulan bir çok SELECTleri gösterir.
|
||||
|
||||
4.8) Sorgularım cok yavaş, ya da indexlerimi kullanmıyorlar. Neden?
|
||||
Indexler her sorgu tarafından otomatik olarak kullanılmazlar. Indexler eğer bir tablonun büyüklüğü minimum bir
|
||||
büyüklükten fazla ise ve sorgu tablodaki satırların sadece küçük bir yüzdesini seçiyorsa kullanılır. Bunun nedeni,
|
||||
index erişiminin neden olduğu raslansal disk erişimi nin diskin ya da tablonun sıralı okunmasından daha yavas
|
||||
olabilmesidir.
|
||||
|
||||
Indexes are not automatically used by every query. Indexes are only used if the table is larger than a minimum size,
|
||||
and the query selects only a small percentage of the rows in the table. This is because the random disk access caused
|
||||
by an index scan can be slower than a straight read through the table, or sequential scan.
|
||||
Bir index'in kullanılıp kullanılmayacağını belirlemek için, PostgreSQL tablo hakkındaki istatistiklere gereksinmesi
|
||||
vardır. Bu istatistikler, VACUUM ANALYZE kullanılarak toplanırlar. Optimizer, istatistikleri kullanarak, tabloda kaç
|
||||
satır olduğunu ve bilir ve indexin kullanılıp kullanılmayacağına daha iyi karar verir. Istatistikler, aynı zamanda en
|
||||
uygun join sırasını ve yöntemini belirlemekte çok önemlidir. İstatistik toplanması, tablo içerikleri değiştikçe
|
||||
periyodik olarak yapılmalıdır.
|
||||
|
||||
To determine if an index should be used, PostgreSQL must have statistics about the table. These statistics are
|
||||
collected using VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer knows how many rows are in the
|
||||
table, and can better determine if indexes should be used. Statistics are also valuable in determining optimal join
|
||||
order and join methods. Statistics collection should be performed periodically as the contents of the table change.
|
||||
|
||||
Indexes are normally not used for ORDER BY or to perform joins. A sequential scan followed by an explicit sort is
|
||||
usually faster than an index scan of a large table.
|
||||
However, LIMIT combined with ORDER BY often will use an index because only a small portion of the table is returned.
|
||||
In fact, though MAX() and MIN() don't use indexes, it is possible to retrieve such values using an index with ORDER
|
||||
BY and LIMIT:
|
||||
Indexler normalde ORDER BY sorguları ya da join işlemlerini gerçekleştirmek için kullanılmazlar. Açık bir sıralamayı
|
||||
takip eden sıralı bir arama (sequential scan), büyük bir tabloda index araması yapmaktan genelde daha hızlıdır.
|
||||
Ancak, ORDER BY ile birleşmiş LIMIT genellikle bir index kullanacaktır; çünkü tablonun sadece belirli bir miktarı
|
||||
döndürülecektir. Aslında, MAX() ve MIN() fonksiyonlarının index kullanmamalarından dolayı, bu gibi değerleri ORDER BY
|
||||
ve LIMIT kullanarak da almak olasıdır:
|
||||
|
||||
SELECT col
|
||||
FROM tab
|
||||
ORDER BY col [ DESC ]
|
||||
LIMIT 1;
|
||||
|
||||
Eðer optimizer'in sequential scan iþleminde hata yaptýðýný düþünüyorsanýz, SET enable_seqscan TO 'off' 'u kullanýnýz
|
||||
ve index scan'in hala hýzlý olup olmadýðýný görmek için testler yapýnýz.
|
||||
Eğer optimizer'ın sıralı arama yapmasının yanlış olduğuna inanıyorsanız, SET enable_seqscan TO 'off' kullanın ve
|
||||
index kullanan aramaların hala daha hızlı olup olmadığını görün.
|
||||
|
||||
LIKE ya da ~ gibi operatorler kullaniyorsanýz, indeksler sadece aþaðýdaki koþullarda kullanýlabilir:
|
||||
LIKE ya da ~ gibi operatörler kullanıyorsanız, index'ler sadece aşağıdaki koşullarda kullanılabilir:
|
||||
|
||||
* Arama dizininin baþý, dizinin baþý ile baðlanmalýdýr. Yani,
|
||||
o LIKE sorgularý % ile baþlamamalýdýr.
|
||||
o Düzenli ifade sorgularý ^ iþe baþlamamalýdýr.
|
||||
* Arama dizininin başı, dizinin başı ile bağlanmalıdır. Yani,
|
||||
o LIKE sorguları % ile başlamamalıdır.
|
||||
o Düzenli ifade sorguları ^ işe başlamamalıdır.
|
||||
* Arama metni bir karakter sınıfı ile başlayamaz. Örnek: [a-e]
|
||||
* ILIKE ve ~* gibi büyük/küçük harfe duyarsýz aramalar indekslerden yararlanmazlar. Onun yerine, bölüm 4.12'de
|
||||
anlatýlan fonksiyonel indeksleri kullanabilirsiniz.
|
||||
* initdb sýrasýnda öntanýmlý C localei kullanýlmalýdýr.
|
||||
* ILIKE ve ~* gibi büyük/küçük harfe duyarsız aramalar index'lerden yararlanmazlar. Onun yerine, bölüm 4.12'de
|
||||
anlatılan fonksiyonel index'leri kullanabilirsiniz.
|
||||
* initdb sırasında öntanımlı C locale'i kullanılmalıdır.
|
||||
|
||||
4.9) query-optimizer in sorgularımı nasıl değerlendirdiğini, işleme soktuğunu nasıl görebilirim?
|
||||
|
||||
EXPLAIN yardım sayfasına bakınız.
|
||||
|
||||
4.10) R-tree index nedir?
|
||||
R-tree index, uzaysal (spatial) verileri indexlemek için kullanılır. Bir hash index, dizi aramalarında (range search)
|
||||
kullanılamaz. B-tree index dizi aramalarında sadece tek boyutlu çalışmaktadır. R-tree, çok boyutlu veriyi destekler.
|
||||
Örneğin, eğer bir R-tree index point veri tipi üzerinde inşa edililebilirse, sistem "select all points within a
|
||||
bounding rectangle" gibi sorgulara daha verimli yanıtlar verecektir.
|
||||
|
||||
An R-tree index is used for indexing spatial data. A hash index can't handle range searches. A B-tree index only
|
||||
handles range searches in a single dimension. R-trees can handle multi-dimensional data. For example, if an R-tree
|
||||
index can be built on an attribute of type point, the system can more efficiently answer queries such as "select all
|
||||
points within a bounding rectangle."
|
||||
Orijinal R-tree tasarımını açıklayan belge:
|
||||
|
||||
The canonical paper that describes the original R-tree design is:
|
||||
|
||||
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf
|
||||
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf
|
||||
on Mgmt of Data, 45-57.
|
||||
|
||||
Bu paperi, Stonebraker'ýn "Readings in Database Systems" kitabýnda bulabilirsiniz.
|
||||
Bu belgeyi, Stonebraker'ın "Readings in Database Systems" kitabında bulabilirsiniz.
|
||||
|
||||
Gömülü R-tree indexleri poligon ve boxları kullanabilir. Teorik olarak, R-tree indexlerin özelliklerini
|
||||
genişletmek bir miktar çaba gerektirir ve bunun nasıl yapılacağına dair bir belgemiz henüz bulunmamaktadır.
|
||||
|
||||
Built-in R-trees can handle polygons and boxes. In theory, R-trees can be extended to handle higher number of
|
||||
dimensions. In practice, extending R-trees requires a bit of work and we don't currently have any documentation on
|
||||
how to do it.
|
||||
|
||||
4.11) Genetic Query Optimizer nedir?
|
||||
|
||||
GEQO modülü, Genetic Algorith(GA) kullanılarak tablolar birleştirildiğinde sorgu optimizasyonunu hızlandırır.
|
||||
It allows the handling of large join queries through nonexhaustive search.
|
||||
|
||||
4.12) Düzenli ifade (Regular Expression) aramalarýný ve büyük/küçük harfe duyarsýz aramalarý nasil yapabilirim?
|
||||
Bu büyük(küçük harfe duyarlý aramalar için indeksi nasil kullanabilirim?
|
||||
|
||||
4.12) Düzenli ifade (Regular Expression) aramalarını ve büyük/küçük harfe duyarsız aramaları nasıl yapabilirim?
|
||||
Bu büyük(küçük harfe duyarlı aramalar için indeksi nasıl kullanabilirim?
|
||||
|
||||
~ operatörü düzenli ifade eşleşmesi ve ~* büyük/küçük harfe duyarsız düzenli ifade eşleşmesi yapar.
|
||||
Büyük/küçük harfe duyarlı olan LIKE'in büyük/küçük harfe duyarsız olan biçini ILIKE'tır ve PostgreSQL
|
||||
|
|
@ -753,7 +749,7 @@ how to do it.
|
|||
|
||||
CREATE INDEX tabindex on tab (lower(col));
|
||||
|
||||
4.13) Bir sorguda, bir alanin "NULL" oldugunu nasil ortaya çýkarabilirim?
|
||||
4.13) Bir sorguda, bir alanin "NULL" oldugunu nasıl ortaya çıkarabilirim?
|
||||
|
||||
Kolonu, IS NULL ve IS NOT NULL ile test edebilirsiniz.
|
||||
|
||||
|
|
@ -779,14 +775,14 @@ BYTEA bytea variable-length byte array (null-byte safe)
|
|||
doldurur; ancak VARCHAR(n) sadece verilen karakterleri saklar.BYTEA binary veri saklamak içindir; ayrıca "NULL" bayt
|
||||
içeren değerleri de saklar. Burada anlatılan üç veri tipi de benzer başarım karakteristiklere sahiptir.
|
||||
|
||||
4.15.1) Nasil serial/otomatik artan(auto-incrementing) bir alan yaratabilirim?
|
||||
4.15.1) nasıl serial/otomatik artan(auto-incrementing) bir alan yaratabilirim?
|
||||
|
||||
PostgreSQL'de SERIAL veri tipi vardır. Bu veri tipi bir sequence ve kolon üzerinde bir indeks yaratır.
|
||||
|
||||
Örnek, aşağıdaki sorgu:
|
||||
|
||||
CREATE TABLE person (
|
||||
id SERýAL,
|
||||
id SERIAL,
|
||||
name TEXT
|
||||
);
|
||||
|
||||
|
|
@ -803,19 +799,16 @@ BYTEA bytea variable-length byte array (null-byte safe)
|
|||
tekil bir sayı olarak alabilirsiniz. Ancak, veritabanınızın dump'ını alıp yeniden yüklerseniz, OID değerlerini
|
||||
koruyabilmek için pg_dump'ın -o parametresini ya da "COPY WITH OIDS" seçeneğini kullanmanız gerekecektir.
|
||||
|
||||
4.15.2) SERIAL giriþinin degerini nasil alabilirim?
|
||||
|
||||
One approach is to retrieve the next SERIAL value from the sequence object with the nextval() function before
|
||||
inserting and then insert it explicitly. Using the example table in 4.15.1, an example in a pseudo-language would
|
||||
look like this:
|
||||
4.15.2) SERIAL girişinin degerini nasıl alabilirim?
|
||||
|
||||
Bir yaklaşım, sequence nesnesindeki SERIAL değerini, veriyi girmeden önce nextval() ile alıp, aldığınız değeri
|
||||
kendinizin girmesidir. 4.15.1'deki örnek tabloyu kullanarak bir örnek verelim:
|
||||
|
||||
new_id = execute("SELECT nextval('person_id_seq')");
|
||||
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
|
||||
|
||||
You would then also have the new value stored in new_id for use in other queries (e.g., as a foreign key to the
|
||||
person table). Note that the name of the automatically created SEQUENCE object will be named
|
||||
<table>_<serialcolumn>_seq, where table and serialcolumn are the names of your table and your SERIAL column,
|
||||
respectively.
|
||||
Diğer sorgular için new_id'de yeni değerin saklanması gerekir. Otomatik olarak yaratılan SEQUENE nesnesinin adı,
|
||||
<tablo adı>_<serial kolonu adı>_seq şeklinde olacaktır (< > işaretleri olmadan).
|
||||
|
||||
Alternatif olarak, atanmış SERIAL değerini, değer girildikten sonra currval() fonksiyonu ile alabilirsiniz:
|
||||
|
||||
|
|
@ -823,8 +816,8 @@ respectively.
|
|||
new_id = execute("SELECT currval('person_id_seq')");
|
||||
|
||||
Son olarak, ön tanımlı değeri bulmak için INSERT ifadesinden dönen OID değerini kullanabilirsiniz; ancak bu
|
||||
en az taþýnabilir çözüm olacaktýr. Perl'de, Edmund Mergl'in DBD:Pg mödülü ile birlikte DBI kullanarak, oid deðeri
|
||||
$sth->execute() çalýþtýrýldýktan sonra $sth->(pg_oid_status) ile alýnabilir.
|
||||
en az taşınabilir çözüm olacaktır. Perl'de, Edmund Mergl'in DBD:Pg mödülü ile birlikte DBI kullanarak, OID değeri
|
||||
$sth->execute() çalıştırıldıktan sonra $sth->(pg_OID_status) ile alınabilir.
|
||||
|
||||
4.15.3) currval() ve nextval() diger kullanicilara sorun yaratmaz mı?
|
||||
|
||||
|
|
@ -838,41 +831,34 @@ respectively.
|
|||
bitene kadar o değer kilitlenmez. Bu, iptal edilen transaction işlemleri nedeniyle boşluklara neden olur.
|
||||
|
||||
4.16) OID nedir? TID nedir?
|
||||
|
||||
OýDs are PostgreSQL's answer to unique row ids. Every row that is
|
||||
created in PostgreSQL gets a unique OýD. All OýDs generated during
|
||||
initdb are less than 16384 (from backend/access/transam.h). All
|
||||
user-created OýDs are equal to or greater than this. By default, all
|
||||
these OýDs are unique not only within a table or database, but unique
|
||||
within the entire PostgreSQL installation.
|
||||
|
||||
PostgreSQL uses OýDs in its internal system tables to link rows
|
||||
between tables. These OýDs can be used to identify specific user rows
|
||||
and used in joins. ýt is recommended you use column type OýD to store
|
||||
OýD values. You can create an index on the OýD field for faster
|
||||
access.
|
||||
|
||||
OýDs are assigned to all new rows from a central area that is used by
|
||||
all databases. ýf you want to change the OýD to something else, or if
|
||||
you want to make a copy of the table, with the original OýDs, there is
|
||||
no reason you can't do it:
|
||||
CREATE TABLE new_table(old_oid oid, mycol int);
|
||||
SELECT old_oid, mycol ýNTO new FROM old;
|
||||
|
||||
OIDler, tekil satır numaralarına PostgreSQL'in yanıtıdır. PostgreSQL'de yaratılan her sayı, tekil bir OID alır.
|
||||
initdb işlemi sırasında yaratılan tüm OID'ler 16384'ten küçüktür (backend/access/transam.h). Kullanıcılar tarafından
|
||||
yaratılan tüm OID'ler bu sayıya eşit ya da bu sayıdan büyüktür. Varsayılan durumda, tüm bu OIDler sadece bir tablo ya
|
||||
da veritabanında değil, tüm PostgreSQL kurulumunda tekildir.
|
||||
|
||||
PostgreSQL OIDleri, tablolar arasında satırları ilişkilendirmek için kendi iç tablolarında kullanır. Bu OIDler
|
||||
belirli kullanıcı satırlarını belirtmek için kullanabilir ve join işlemlerinde kullanılır. OID değerlerini saklamak
|
||||
için OID kolon tipini kullanmanız önerinir. Daha hızlı bir erişim için, OID alanında bir index yaratabilirsiniz.
|
||||
|
||||
OID'ler yeni satırlara, tüm veritabanları tarafında kullanılan ortak bir alandan atanırlar. Eğer OID'i başka bir
|
||||
değere eşitlemek isterseniz ya da tablonun bir kopyasını orijinal OIDler ile çıkarmak isterseniz, bu mümkündür:
|
||||
|
||||
CREATE TABLE new_table(old_OID OID, mycol int);
|
||||
SELECT old_OID, mycol ıNTO new FROM old;
|
||||
COPY new TO '/tmp/pgtable';
|
||||
DELETE FROM new;
|
||||
COPY new WýTH OýDS FROM '/tmp/pgtable';
|
||||
COPY new WITH OIDS FROM '/tmp/pgtable';
|
||||
|
||||
OýDs are stored as 4-byte integers, and will overflow at 4 billion. No
|
||||
one has reported this ever happening, and we plan to have the limit
|
||||
removed before anyone does.
|
||||
|
||||
TIDs are used to identify specific physical rows with block and offset
|
||||
values. TýDs change after rows are modified or reloaded. They are used
|
||||
by index entries to point to physical rows.
|
||||
OIDler 4-bit tamsayı olarak saklanırlar ve 4 milyarda overflow olacaktır. Kimse bu sayıya ulaştığına dair bir bilgi
|
||||
iletmedi ve bu sınırı kimse bu sınıra ulaşmadan kaldıracağız.
|
||||
|
||||
TIDler, belirli fiziksel satırlar block ve offset değerleri ile belirtmekte kullanılır. TIDler, satırlar değiştiğinde
|
||||
ya da yeniden yüklendiğinde değişirler. Index girdileri tarafından fiziksel satırları göstermek için kullanılırlar.
|
||||
|
||||
4.17) PostgreSQL'de kullanılan bazı terimlerin anlamları nelerdir?
|
||||
|
||||
Kaynak kodun bir kýsmý ve eski belgeler, daha genis kullaným alaný olan terimleri
|
||||
Kaynak kodun bir kısmı ve eski belgeler, daha geniş kullanım alanı olan terimleri
|
||||
kullanırlar. Bunların bazıları:
|
||||
|
||||
* table, relation, class
|
||||
|
|
@ -892,31 +878,31 @@ respectively.
|
|||
|
||||
4.18) Neden "ERROR: Memory exhausted in AllocSetAlloc()"? hatasını alıyorum?
|
||||
|
||||
Sisteminizde sanal belleginizi tüketmis olabilirsiniz, ya da çekirdeginiz
|
||||
belli kaynaklar icin düþük bir sýnýra sahip olabilir. postmasteri baslatmadan önce
|
||||
asagidakileri deneyebilirsiniz:
|
||||
Sisteminizde sanal belleğinizi tüketmis olabilirsiniz, ya da çekirdeğiniz
|
||||
belli kaynaklar icin düşük bir sınıra sahip olabilir. Postmaster'i başlatmadan önce
|
||||
aşağıdakileri deneyebilirsiniz:
|
||||
|
||||
ulimit -d 262144
|
||||
limit datasize 256m
|
||||
|
||||
Kabuğunuza bağlı olarak, bunlardan sadece biri olumlu sonuç verecektir, ama
|
||||
bu işlem veri segment sınırınızı arttıracak, ve belki de sorgunuzun tamamlanmasını
|
||||
saglayacaktýr. Bu komut, varolan isleme (current process) ve komut çalýstýrýldýktan
|
||||
sonraki tüm alt islemlere uygulanir. Eger SQL istemcinizle, backendin çok fazla veri
|
||||
döndürmesi nedeniyle bir sorun yasýyorsanýz, bunu istemciyi baslatmadan önce deneyiniz.
|
||||
saglayacaktır. Bu komut, varolan sürece (current process) ve komut çalıstırıldıktan
|
||||
sonraki tüm alt islemlere uygulanır. Eğer SQL istemcinizle, backendin çok fazla veri
|
||||
döndürmesi nedeniyle bir sorun yaşıyorsanız, bunu istemciyi başlatmadan önce deneyiniz.
|
||||
|
||||
4.19) Hangi PostgreSQL sürümünü çalýstýrdýgýmý nasil görebilirim?
|
||||
4.19) Hangi PostgreSQL sürümünü çalıstırdıgımı nasıl görebilirim?
|
||||
|
||||
psql arabiriminde, select version(); yazýnýz.
|
||||
psql arabiriminde, SELECT version(); yazınız.
|
||||
|
||||
4.20) Neden large-object islemlerim, "invalid large obj descriptor"? hatasını veriyor?
|
||||
|
||||
Large object islemlerinizin uclarina, yani lo_open ... lo_close komutlarýnýn çevresine,
|
||||
BEGIN WORK ve COMMIT koymanýz gerekmektedir;
|
||||
Large object işlemlerinizin uçlarına, yani lo_open ... lo_close komutlarının çevresine,
|
||||
BEGIN WORK ve COMMIT koymanız gerekmektedir.
|
||||
|
||||
Eger ODBC gibi bir istemci arabirimi kullanıyorsanız, auto-commit'i kapatmanız gerekebilir.
|
||||
|
||||
4.21) Su andaki zamaný öntanýmlý deger olarak kabul eden How do ý create a column that will default to the current time?
|
||||
4.21) Şu andaki zamanı öntanımlı değer olarak kabul eden kolonu nasıl yaratabilirim?
|
||||
|
||||
Alttakini kullanabilirsiniz:
|
||||
|
||||
|
|
@ -924,25 +910,29 @@ respectively.
|
|||
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
|
||||
|
||||
4.22) Neden IN kullanan subquerylerim çok yavas?
|
||||
|
||||
Currently, we join subqueries to outer queries by sequentially scanning the result of the subquery for
|
||||
each row of the outer query. IN' i EXISTS ile deðiþtirerek bir çözüme ulaþýlabilir.
|
||||
|
||||
SELECT *
|
||||
7.4 sürümünden önce, subqueryler. Eğer subquery sadece birkaç satır ve outer query bol sayıda satır döndürüyorsa, IN
|
||||
en hızlısıdır. Sorguları hızlandırmak için IN yerine EXISTS kullanın:
|
||||
|
||||
SELECT *
|
||||
FROM tab
|
||||
WHERE col1 ýN (SELECT col2 FROM TAB2)
|
||||
WHERE col IN (SELECT subcol FROM subtab);
|
||||
|
||||
to:
|
||||
SELECT *
|
||||
sorgusunu, aşağıdaki ile değiştirin:
|
||||
|
||||
SELECT *
|
||||
FROM tab
|
||||
WHERE EXýSTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
|
||||
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
|
||||
|
||||
Bu sýnýrlamayý ilerdeki sürümlerimizde düzeltmeyi planlamaktayýz.
|
||||
Bunun hızlı olabilmesi için, subcol'un indekslenmiş bir kolon olması gerekmektedir.
|
||||
|
||||
7.4 sürümü ve sonrasında, IN aslında normal sorgularla aynı karmaşık join tekniklerini kullanır ve EXISTS'e tercih
|
||||
edilir.
|
||||
|
||||
4.23) Outer join islemini nasil yapabilirim?
|
||||
4.23) Outer join islemini nasıl yapabilirim?
|
||||
|
||||
PostgreSQL outer joins islemlerini SQL standartlarýný kullanarak gerçeklestirmektedir.
|
||||
Asagida 2 örnek bulunmaktadýr:
|
||||
PostgreSQL outer join işlemlerini SQL standartlarını kullanarak gerçekleştirmektedir.
|
||||
Aşağıda 2 örnek bulunmaktadır:
|
||||
|
||||
SELECT *
|
||||
FROM t1 LEFT OUTER JOıN t2 ON (t1.col = t2.col);
|
||||
|
|
@ -952,9 +942,9 @@ SELECT *
|
|||
SELECT *
|
||||
FROM t1 LEFT OUTER JOıN t2 USıNG (col);
|
||||
|
||||
Bu özdes sorgular t1.col ' i t2.col'ye join ederler ve ayný zamanda t1'deki unjoined satýrlarý
|
||||
(t2'de eslenmenis olanlarla) döndürürler. RýGHT JOýN t2'nin unjoined satýrlarýný ekleyecektir.
|
||||
Bir FULL join, eþleþmiþ btün satýrlarý ve t1 ile t2'den tüm baðlanmamýþ (unjoined) satýrlarý alýr.
|
||||
Bu özdeş sorgular t1.col ' i t2.col'ye join ederler ve aynı zamanda t1'deki unjoined satırları
|
||||
(t2'de eşlenmenis olanlarla) döndürürler. RIGHT JOıN t2'nin unjoined satırlarını ekleyecektir.
|
||||
Bir FULL join, eşleşmiş bütün satırları ve t1 ile t2'den tüm bağlanmamış (unjoined) satırları alır.
|
||||
OUTER sözcüğü seçimseldir ve LEFT, RIGHT ve FULL join işlemlerinde olduğu kabul edilir. Sıradan
|
||||
join işlemleri INNER join olarak adlandırılır.
|
||||
|
||||
|
|
@ -970,28 +960,28 @@ SELECT *
|
|||
WHERE tab1.col1 NOT ıN (SELECT tab2.col1 FROM tab2)
|
||||
ORDER BY col1
|
||||
|
||||
4.24) Ayni andan birden fazla veritabaninda nasil islem yapabilirim?
|
||||
|
||||
4.24) Aynı anda birden fazla veritabanında nasıl işlem yapabilirim?
|
||||
|
||||
Mevcut veritabanınız dısındaki baska bir veritabanınızı sorgulamanızın bir yolu bulunmamaktadır.
|
||||
bunun nedeni, PostgreSQL'in veritabanına özel sistem katalogları yüklemesidir. Bu nedenle,
|
||||
cross-database bir sorgunun nasil davranacagýný kestirmek zordur.
|
||||
cross-database bir sorgunun nasıl davranacagını kestirmek zordur.
|
||||
|
||||
contrib/dblink fonksiyon çaðrýlarýný kullanarak cross-database sorgulara izin verid. Tabii ki,
|
||||
bir istemci degisik veritabanlarýna ayný anda erisim saglayabilir ve bilgiyi bu sekilde
|
||||
birlestirebilir.
|
||||
contrib/dblink fonksiyon çağrılarını kullanarak cross-database sorgulara izin vermektedir. Tabii ki,
|
||||
bir istemci değişik veritabanlarına aynı anda erişim sağlayabilir ve bilgiyi bu sekilde
|
||||
birleştirebilir.
|
||||
|
||||
4.25) Bir fonksiyondan nasıl çoklu satır ya da kolon döndürebilirim?
|
||||
|
||||
7.3 sürümünde, bir fonksiyondan kolaylıkla çoklu satır ya da sütun döndürebilirsiniz.
|
||||
|
||||
http://techdocs.postgresql.org/guides/SetReturningFunctions.
|
||||
http://techdocs.postgresql.org/guides/SetReturningFunctions .
|
||||
|
||||
4.26) Neden Pl/PgSQL fonksiyonlarý içinden güvenli bir þekilde tablo yaratma/kaldýrma iþlemlerini yapamýyoruz?
|
||||
4.26) Neden PL/pgSQL fonksiyonları içinden güvenli bir şekilde tablo yaratma/kaldırma işlemlerini yapamıyoruz?
|
||||
|
||||
PL/PgSQL fonksiyon içerikleri cacheler. Bunun istenmeyen bir tarafý, eðer bir PL/PgSQL fonksiyonu geçici bir
|
||||
PL/pgSQL fonksiyon içerikleri cacheler. Bunun istenmeyen bir tarafı, eğer bir PL/pgSQL fonksiyonu geçici bir
|
||||
tabloya erişiyorsa ve bu tablo ileride kaldırılıp yeniden oluşturulduktan sonra fonksiyon yeniden çağrılırsa,
|
||||
fonksiyon çalışmayacaktır; çünkü cachelenmiş fonksiyon hala eski geçici tabloyu gösteriyor olacaktır. Çözüm,
|
||||
geçici tablo eriþimleri için PL/PgSQL'de EXECUTE kullanmaktýr. Bu, sorgunun her seferinde yeniden iþlenmesini
|
||||
geçici tablo erişimleri için PL/pgSQL'de EXECUTE kullanmaktır. Bu, sorgunun her seferinde yeniden işlenmesini
|
||||
sağlayacaktır.
|
||||
|
||||
4.27) Hangi replikasyon seçenekleri bulunmaktadır?
|
||||
|
|
@ -1005,33 +995,36 @@ SELECT *
|
|||
4.28) Hangi şifreleme seçenekleri bulunmaktadır?
|
||||
|
||||
* contrib/pgcrypto SQL sorgularında kullanılabilmesi için şifreleme fonksiyonları içermektedir.
|
||||
* Ýstemciden sunucuya iletiþimi þifrelemenin tek yolu, pg_hba.conf içinde hostssl kullanmaktýr.
|
||||
* İstemciden sunucuya iletişimi şifrelemek için, sunucuda ssl seçeneği postgresql.conf içinde açık olmalıdır.
|
||||
Ayrıca,pg_hba.conf dosyası içinde host ya da hostssl kaydı mutlaka olmalıdır ve istemci sslmode
|
||||
kapatılmamalıdır. (Aynı zamanda,PostgreSQL'in doğal SSL bağlantıları dışında ssh ya da ssl gibi 3.parti
|
||||
şifrelenmiş veri iletimi de mümkündür.)
|
||||
* Veritabanı kullanıcı adı ve şifreleri 7.3 sürümü ile birlikte otomatik olarak şifrelenirler. Önceki
|
||||
sürümlerde, postgresql.conf içindeki PASSWORD_ENCRYPTION seçeneðini aktif hale getirmeniz gerekmektedir.
|
||||
sürümlerde, postgresql.conf içindeki PASSWORD_ENCRYPTION seçeneğini aktif hale getirmeniz gerekmektedir.
|
||||
* Sunucunun kendisini şifreli dosya sistemi üzerinde çalıştırabilirsiniz.
|
||||
|
||||
_________________________________________________________________
|
||||
|
||||
PostgreSQL Özelliklerini Genişletmek
|
||||
|
||||
5.1) Kullanici-tanimli bir fonksiyon yazdim. psql'de çalistirdigim zaman neden core dump ediyor?
|
||||
5.1) Kullanıcı-tanımlı bir fonksiyon yazdım. psql'de çalıştırdığım zaman neden core dump ediyor?
|
||||
|
||||
Sorunun nedeni birden fazla sey olabilir. Kullanici-tanimli fonksiyonunuzu stand-alone bir programda
|
||||
calistirmayi deneyiniz.
|
||||
|
||||
5.2) PostgreSQL'e nasil yeni tipler/fonksiyonlar ekleyeiblirim?
|
||||
5.2) PostgreSQL'e nasıl yeni veri tipleri/fonksiyonlar ekleyebilirim?
|
||||
|
||||
Çalýsmalarýnýzý pgsql-hackers e-posta listesine gönderiniz. Kodunuz incelendikten sonra
|
||||
Çalışmalarınızı pgsql-hackers e-posta listesine gönderiniz. Kodunuz incelendikten sonra
|
||||
/contrib dizinine konacaktır.
|
||||
|
||||
5.3) Bir tuple dondürmek icin bir C fonksiyonunu nasil yazarým?
|
||||
5.3) Bir tuple döndürmek icin bir C fonksiyonunu nasıl yazarım?
|
||||
|
||||
PostgreSQL 7.3 sürümü ile birlikte, C, PL/PgSQL ve SQL kullanýlarak tablo-döndüren
|
||||
PostgreSQL 7.3 sürümü ile birlikte, C, PL/pgSQL ve SQL kullanılarak tablo-döndüren
|
||||
fonksiyonlar tamamen desteklenmektedir. Ayrıntılı bilgi için "Programmer's Guide" a
|
||||
bakabilrisiniz. Bir örneði contrib/tablefunc içinde bulabilirsiniz.
|
||||
bakabilirsiniz. Bir örneği contrib/tablefunc içinde bulabilirsiniz.
|
||||
|
||||
5.4) Bir kaynak dosyasında değişiklik yaptım. Yeniden derlememe rağmen değişiklik
|
||||
geçerli olmuyor. Neden?
|
||||
geçerli olmuyor. Neden?
|
||||
|
||||
Makefile'lar include dosyaları için tam bir bağımlılık içermezler.
|
||||
Öncelikle make clean, ardından da baska bir make işlemi yapmanız gerekir.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue