Re: bitstring ya da numerik tur uzerinde "bit count" alabilmek

On 12/4/06, Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> wrote:
> On Dec 04 04:27, Kerem Hadimli wrote:
> > Gelistirmekte oldugum yazilimda, iki verinin belli 'flag'lere gore
> > uyumuna yonelik siralama yapmak istiyorum.
> > Flag dedigim sey boolean ve sayica 200-300 u bulabiliyor.
> >
> > Yapmak istedigim sey, elimdeki bir tane veriye (300 tane flag iceren)
> > en uygun verileri siralatmak, sadece TRUE olanlar yonunden.
> >
> > Test asamasi icin, konseptin kalaninin netlesmesi icin, 300 tane
> > boolean kolon kullanip,
>
> Aman deyim! Bir tabloda 300 sütununuz varsa ya çok ama çok uç bir
> durumla uğraşıyorsunuz, ya da kesinlikle bir şeyleri yanlış
> yapıyorsunuz.

evet yanlis, zaten 300 kolonun amaci, projenin buraya bagimli olan
kisimlari, buranin implementation asamasina takilmadan halledilebilsin
diye bir placeholder sadece :)

ilk asamada bu sorunun implementation'u, projenin kalanindan bagimsiz
oldugu icin, bit(300) kullanip hemen cozmektense (ve cozulene kadar
projenin kalanini tikamasindansa), kalan kisimlar tamamlanana kadar
burasi icin idareten bir implementation kullanarak, buranin gercek
implementationunu sona birakmak daha uygun gorundugu icin; tek
bit(300) kullanip da o anda cozumuyle vakit kaybetmedim, artik gercek
implementationuna geldi sira :) Sonucta, onemli olan girdi ve ciktinin
belli sekilde olmasi, girdiden ciktinin olusturulmasi icin yapilan
islemler, burayi kullanacak kisimlari etkilemiyor

> > select'lerde ORDER BY CAST(a1 AS integer) + CAST(a2 AS integer) +
> > CAST(a6 AS integer) DESC gibisinden bir sekilde idare ettim (TRUE
> > olmasini aradigim kolonlari ORDER BY'a ekleyerek), fakat veri
> > buyuklugu acisindan production seviyesinde bu sekilde kullanilmasi
> > imkansiz.
> >
> > Yapmak istedigim sey, 2 tane bitstring'i AND'ledikten sonra, sonuc
> > bitstring'inde kac adet 1 oldugunu almak, ve buna gore siralama yapmak
> > (ayni zamanda bu degeri de ogrenmek tabi ki), ozetle 0011110101 icin 5
> > dondurecek bir fonksiyon.
>
> Evvela integer/boolean ile uğraşmaktan vazgeçip PostgreSQL size
> sunduğu bit(n) veri tipine bir böz atın. Ardından gerekli bitwise
> operatörleri kullanarak istediğiniz kolaylıkla yapabilirsiniz. (Bu
> konuda olmazsa ben yine yardımcı olurum.)
>
> Ama bence bir şeyleri yanlış yapıyor gibisiniz. Bitwise veri saklayıp
> işlemeyi ben de çok severim ama düşünüyorum da... bitwise veri
> içindeki birlerin sayısı bana burada yanlış bir kullanım yer olduğunu
> çağrıştırıyor. Tam olarak ne yapmaya çalışıyorsunuz? Bu 300 tane flag
> ne tür veriler içeriyor. Bunu biraz daha açarsanız sevinirim. Eldeki
> bilgiler ile düşünüyorum da... Verinin çok daha mantıklı bir
> katagorizasyonu mümkün olmalı.
>

Simdi, ihtiyaci aciklayayim ilk once.

Karsilastirilacak olan veri, eldeki urunlerin ozelikleri ile [tabloda
varolan veriler], musterinin beklentisi, aradigi urunun ozellikleri
(yani, "aradigim urunde A C D ozellikleri benim icin onemli, B E F G
ozellikleri farketmez" demesi musterinin)

Yapmak istedigim sey, yukaridaki ornekten devam ederek, elde A C D
ozellikleri olan urun olmasa bile, "bakin, en basta A D ozelligi olan
su urun var, ayrica isterseniz C D ozelligi olan su urun var, daha
sonra sadece A ozelligi olan su urun var" diye bir siralama
koyabilmek.

Ayni yazilimin birden fazla yerde kullanilacak olmasi, ve bu
ozelliklerin dinamik olmasi ihtiyaciyla, en uygun cozumu urun
ozelliklerini bitstring (bit(n) sanirim) olarak saklayarak, musterinin
istegi olan bitstring'le ANDlemek olarak goruyorum (dinamik'le kastim,
(ucta bir ihtiyac olmadikca) kullanim esnasinda degil, ama ilk kurulum
esnasinda program yapisi / queryler / veritabani yapisini degistirmeye
gerek kalmadan ozellestirilebilmesi).

Dedigim gibi, ilk asamada, bitstring uzerinden "kac bitin degeri var"
bilgisini almaya yonelik bir sey bulamadigim icin, kalan kisimda
gecikme yasamamak icin bitstring'i ayri ayri boolean'larla
gerceklestirdim, bu degisecek haliyle, 10 urunde test edilebiliyor,
1000 urun bile olsa sunucunun gereksiz yere cok fazla efor sarfedecegi
garanti, ama degismesi icin, ayni fonksiyonelligin saglanmasi
gerekiyor :)

okudugum bitcount metinlerinde, 16bitlik onceden hesaplanmis
tablolardan yapilan sayma isleminin cok da yavas olmadigini gordum,
zaten tek tek toplama yapmak istemiyorum. Bu yuzden C ile bir eklenti
fonksiyon yapilabilir diye dusunuyorum, ama daha uygun bir oneri varsa
tercih ederim tabii ki :) sonucta 3000 degil, 300 alana ihtiyacim
oldugu icin, her 16 alanin bit sayisini, onceden hesaplanmis bir
tablodan a[deger] olarak cekmek mumkun, 320 alan icin 20 adet integer
toplamasi eder bu da, makul gorunuyor. Ornegin, eleman basina,
collation kullanan bir string siralamasindan daha kotu performans
vermeyecegini dusunuyorum; karsilastirmak icin yapilan overhead icin
iyi bir ornek olabilir :)

tesekkurler,
Kerem HADIMLI

> > bunun en ideal yolu nedir, pgSQL ile bir fonksiyon yazmak pek verimli
> > olmaz gibi gorundu, c ile fonksiyon mu eklemeli (gordugum kadariyla
> > cok karmasik bir APIsi yok postgresql'in, yine de gozatmaktan oteye
> > gecmedim, belki bitstringler degil ama, 32 bitlik integerlarla calisan
> > bir fonksiyon ekleyip, veritabanimi buna gore olusturabilirim 10 adet
> > 32 bitlik integer'da tutacak gibi), indekslere guvenip su anki haliyle
> > mi birakmali (cok fazla sayida kolon oldugu icin pek verimli olmaz
> > diye dusunuyorum), hazir boyle bir sey var midir, ya da baska
> > onerileriniz bu ihtiyaca yonelik?
>
> Dediğim gibi, önce bir asıl problemi görelim. Bu noktada yapılacak
> yardımlar, sizin yanlış tasarımınız üzerinde doğru adımlar atmaya
> çalışmak gibi olacaktır. Onun yerine baştan verileri düzgün bir
> tasarım içinde tablolarda saklamanın daha sağlıklı olacağı aşikar
> gözüküyor bence.
>
>
> İyi çalışmalar.
>