[pgadmin-hackers] SVN Commit by dpage: r4777 - in branches/REL-1_4_0_PATCHES/pgadmin3: i18n pkg/win32/src (fwd)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolai teşekkürler. pgadmin 1.4.1'ye Türkçe menüler tekrar gelecek...

- ---------- Forwarded message ----------
Date: Thu, 1 Dec 2005 13:51:21 GMT
From: svn(at)pgadmin(dot)org
To: pgadmin-hackers(at)postgresql(dot)org
Subject: [pgadmin-hackers] SVN Commit by dpage: r4777 - in
branches/REL-1_4_0_PATCHES/pgadmin3: i18n pkg/win32/src

Author: dpage
Date: 2005-12-01 13:51:21 +0000 (Thu, 01 Dec 2005)
New Revision: 4777

Modified:
branches/REL-1_4_0_PATCHES/pgadmin3/i18n/Makefile.am
branches/REL-1_4_0_PATCHES/pgadmin3/pkg/win32/src/i18ndata.wxs
Log:
Re-enable Turkish translation

Modified: branches/REL-1_4_0_PATCHES/pgadmin3/i18n/Makefile.am
===================================================================
- --- branches/REL-1_4_0_PATCHES/pgadmin3/i18n/Makefile.am 2005-12-01 13:49:51 UTC (rev 4776)
+++ branches/REL-1_4_0_PATCHES/pgadmin3/i18n/Makefile.am 2005-12-01 13:51:21 UTC (rev 4777)
@@ -13,7 +13,7 @@
# at http://www.pgadmin.org/translation.php. These are the only ones
# that will be installed, but all will be shipped in the source tarball.

- -PUB_TX = af_ZA ar_SA ca_ES de_DE es_ES fi_FI fr_FR ja_JP nl_NL pl_PL sl_SI
+PUB_TX = af_ZA ar_SA ca_ES de_DE es_ES fi_FI fr_FR ja_JP nl_NL pl_PL sl_SI tr_TR

EXTRA_DIST = \

Modified: branches/REL-1_4_0_PATCHES/pgadmin3/pkg/win32/src/i18ndata.wxs
===================================================================
- --- branches/REL-1_4_0_PATCHES/pgadmin3/pkg/win32/src/i18ndata.wxs 2005-12-01 13:49:51 UTC (rev 4776)
+++ branches/REL-1_4_0_PATCHES/pgadmin3/pkg/win32/src/i18ndata.wxs 2005-12-01 13:51:21 UTC (rev 4777)
@@ -122,12 +122,12 @@
<File Id="i18n_sr_YU.pgadmin3.mo" Name="pgadmin3.mo" DiskId="1" src="../../i18n/sr_YU/pgadmin3.mo" />
</Component>
</Directory> -->
- -<!-- <Directory Id="i18n_tr_TR" Name="tr_TR">
+ <Directory Id="i18n_tr_TR" Name="tr_TR">
<Component Id="i18n_tr_TR" Guid="CA9BEAC9-4EC5-4502-95FD-688625E0CAC2">
<File Id="i18n_tr_TR.pgadmin3.mo" Name="pgadmin3.mo" DiskId="1" src="../../i18n/tr_TR/pgadmin3.mo" />
<File Id="i18n_tr_TR.wxstd.mo" Name="wxstd.mo" DiskId="1" src="../../i18n/tr_TR/wxstd.mo" />
</Component>
- - </Directory> -->
+ </Directory>
<!-- <Directory Id="i18n_zh_CN" Name="zh_CN">
<Component Id="i18n_zh_CN" Guid="A07BDC01-EDAB-4582-B752-622F2C57617A">
<File Id="i18n_zh_CN.pgadmin3.mo" Name="pgadmin3.mo" DiskId="1" src="../../i18n/zh_CN/pgadmin3.mo" />

- ---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDjwCG4zE8DGqpiZARAsK4AKCMZ+Lgn4XY+Muw6m2sMDDUyFWCfwCfXhua
5r0cqujVl3IkA1x3TusbsME=
=J9YR
-----END PGP SIGNATURE-----
>From pgsql-tr-genel-owner(at)postgresql(dot)org Thu Dec 1 18:14:20 2005
X-Original-To: pgsql-tr-genel-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (av.hub.org [200.46.204.144])
by postgresql.org (Postfix) with ESMTP id F035B9DD6C4
for <pgsql-tr-genel-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu, 1 Dec 2005 18:14:18 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 16225-01
for <pgsql-tr-genel-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Thu, 1 Dec 2005 18:14:13 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from web26403.mail.ukl.yahoo.com (web26403.mail.ukl.yahoo.com [217.146.176.27])
by postgresql.org (Postfix) with SMTP id 2290B9DD6C6
for <pgsql-tr-genel(at)PostgreSQL(dot)org>; Thu, 1 Dec 2005 18:14:11 -0400 (AST)
Received: (qmail 25495 invoked by uid 60001); 1 Dec 2005 21:37:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com.tr;
h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
b=pxbYa4D7xVDpy+u0xJ0luIpWXfbK3YW4ty+SObPf395Hs9rkizw4Qv0cPQAHWLiKs1+StvhrIJbs7edNTTr/TvLou80y+Od8/FzuSxDPSyohryewfMOKsejtAiCc3zf3MHwTwJbdGyH9barq5X5kFKxrzJjTJJTBABAMTMtnC90= ;
Message-ID: <20051201213738(dot)25493(dot)qmail(at)web26403(dot)mail(dot)ukl(dot)yahoo(dot)com>
Received: from [85.101.135.134] by web26403.mail.ukl.yahoo.com via HTTP; Thu, 01 Dec 2005 23:37:38 EET
Date: Thu, 1 Dec 2005 23:37:38 +0200 (EET)
From: acemi linux <acemi_nix(at)yahoo(dot)com(dot)tr>
Subject: =?utf-8?q?Yan=C4=B1t:=20Re:=20=20Veri=20=C3=B6zeti,=20Lik?=
=?utf-8?q?=20e=20ile=20arama=20performans'=C4=B1?=
To: pgsql-tr-genel(at)PostgreSQL(dot)org
In-Reply-To: <Pine(dot)LNX(dot)4(dot)63(dot)0512011553330(dot)21217(at)mail(dot)kivi(dot)com(dot)tr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-248733260-1133473058=:25300"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=2.489 required=5 tests=[HTML_10_20=0.945,
HTML_MESSAGE=0.001, SUBJECT_ENCODED_TWICE=1.543]
X-Spam-Score: 2.489
X-Spam-Level: **
X-Archive-Number: 2005121/2
X-Sequence-Number: 394

--0-248733260-1133473058=:25300
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

merhaba

öncelikle postgre ye yeni ama veritabanlarına pekte yeni olmadığımı belirterek.
2. önerinizi pek makul bulmadığımı söyleyebilirim. veritabanı kullanmanın tek performans olmadığı gibi tek nedeni veri güvenliğide değildir bu 2 side şarttır.

2 milyon satırlık bir dosyada '1__0017_______02__' nu arıycaksınız ve bu sırada veri girişide olabilecek. bunun için dosyayı devamlı açık konumda tutmanız gerekli veritabanlarının da kendi dosyalarına yaptığı gibi. ama kişi bunu php ile yapıcak. eğer bellekte tutma ihtimali varsa sanırım postgresqlunda var heap tarzı bi tablo kullanabilir ama ani bi resetde veya kitlenmede veriler gidecek.

benim tavsiyem 3 tarz test yapman ama ondan önce kolon tipini değiştir varchar(50) yerine char(18) kullan bence. (sabit 18 karakter var). ve ilan_id yi int yapman. sistem çok popüler olana kadar yetecektir integer.

* '1__0017_______02__' yöntemi ile idleri çekip diğer tablodanda gerekli verileri al bunun süresini ölç

* '1__0017_______02__' yöntemi ile diğer tabloyu joinle birleştir ölç

* diğer tabloda gerekli indexleri yapıp tek ordan veri çek ve süre ölç

bunları değişik kolon seçeneklerinde aramalar yaparak dene.

ayrıca aslında bu sadece veri tabanı konusuda değil.

işin içine php yi sokmalısın. mesela her aramayı 1 saatliğine cachele. en çok aranan 100 arama yı anlık cachele.

bu konuda sana şöyle bir örnek veriyim. geçende google da yaptığım bir arama 1.06 saniyede sonuç döndürdü ve aynı aramayı tekrar yaptım bilerek ve 0.1 saniye tuttu bu sefer. mysql aksini belirtmezsen cacheleme yapıyor kendi için postgre yapıyormu bilmiyorum ama bunu php ile yaparsan bu kısmı daha iyi edersin.


---------------------------------
Yahoo! kullaniyor musunuz?
Istenmeyen postadan biktiniz mi? Istenmeyen postadan en iyi korunma Yahoo! Posta’da
http://tr.mail.yahoo.com
--0-248733260-1133473058=:25300
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

merhaba<br> <br> öncelikle postgre ye yeni ama veritabanlarına pekte yeni olmadığımı belirterek.<br> 2. önerinizi pek makul bulmadığımı söyleyebilirim. veritabanı kullanmanın tek performans olmadığı gibi tek nedeni veri güvenliğide değildir bu 2 side şarttır.<br> <br> 2 milyon satırlık bir dosyada '1__0017_______02__' nu arıycaksınız ve bu sırada veri girişide olabilecek. bunun için dosyayı devamlı açık konumda tutmanız gerekli veritabanlarının da kendi dosyalarına yaptığı gibi. ama kişi bunu php ile yapıcak. eğer bellekte tutma ihtimali varsa sanırım&nbsp; postgresqlunda var heap tarzı bi tablo kullanabilir ama ani&nbsp; bi resetde veya kitlenmede veriler gidecek.<br> <br> benim tavsiyem 3 tarz test yapman ama ondan önce kolon tipini değiştir varchar(50) yerine char(18) kullan bence. (sabit 18 karakter var).&nbsp; ve ilan_id yi int yapman. sistem çok popüler olana kadar yetecektir integer.<br> <br> * '1__0017_____
__02__'
yöntemi ile idleri çekip diğer tablodanda gerekli verileri al bunun süresini ölç<br> <br> * '1__0017_______02__' yöntemi ile diğer tabloyu joinle birleştir ölç<br> <br> * diğer tabloda gerekli indexleri yapıp tek ordan veri çek ve süre ölç<br> <br> bunları değişik kolon seçeneklerinde aramalar yaparak dene.<br> <br> ayrıca aslında bu sadece veri tabanı konusuda değil.<br> <br> işin içine php yi sokmalısın. mesela her aramayı 1 saatliğine cachele. en çok aranan 100 arama yı anlık cachele.<br> <br> bu konuda sana şöyle bir örnek veriyim. geçende google da yaptığım bir arama 1.06 saniyede sonuç döndürdü ve aynı aramayı tekrar yaptım bilerek ve 0.1 saniye tuttu bu sefer. mysql aksini belirtmezsen cacheleme yapıyor kendi için postgre yapıyormu bilmiyorum ama bunu php ile yaparsan bu kısmı daha iyi edersin.<br> <p>
<hr size="1"><FONT face=Arial size=-1>Yahoo! kullaniyor musunuz?<br>
Istenmeyen postadan biktiniz mi? Istenmeyen postadan en iyi korunma
Yahoo! Posta’da<br><a href="http://tr.mail.yahoo.com/">http://tr.mail.yahoo.com</a></font>
--0-248733260-1133473058=:25300--