[mhmtmlh]

Merhaba;

urunid
urunadi
aciklama

gibi bir tablom var.Arama formundan gelen veriden şu şekilde sonuçlar almak istiyorum; kelime "çek" ise urunadi alaninda "çiçek" yazıyorsa kabul etmesin ancak "çekiç" yazıyorsa alsın.

Bunu

SELECT * FROM uruntablosu WHERE uruadi LIKE 'kelime%' or urunadi LIKE '% kelime%'

şeklinde bir sorguyla yaptım ancak veritabanında örneğin "1-Çekiç" gibi bir ifade varsa tabi bunu bulmuyor.Çözüm olarak REGEXP kullandım ve

SELECT * FROM uruntablosu WHERE uruadi REGEXP '[0-9_-)( ]kelime%'

gibi bir sorgu yazdım, işimi gördü ancak sorgu süresi 2-3 katına çıktı.Çözüm önerinizi paylaşabilirseniz sevinirim.

Teşekkürler...
Kolay gelsin...

[BYK]

İstediğiniz şeyi SQL cümlesinde REGEXP'den başka bir işleç(operatör)le yapma şansınız yok gibi gözüküyor. Açıklama alanının uzunluğunu azaltmak işe yarayabilir. Tam metin araması(full text search) yaptığınız için bu alana göre yapacağınız herhangi bir dizinleme(indexleme) performansa çok bir katkı sağlamayacaktır.

Bir başka pek tercih edilmeyen yöntem ise veritabanından "%kelime%" bilgierini çekip kod içerisinde diğer değerleri ayıklamak olabilir. Normalde tüm filtreleme işini veritabanı motoruna yaptırıp olabildiğince az çağrı ile çekilebilecek en az veriyi çekmek istenir optimizasyon için ama böyle bir durumda bir kısmını veritabanı motoruyla bir kısmını da kendi yazacağınız kodla süzmek performansı arttırabilir.

[mhmtmlh]

Teşekkürler @BYK,
Arama yaptığım tüm alanlara index uygulamıştım, bu optimizasyon sorunuyla karşılaşınca "multiple column index" uygulamayı düşünmüştüm ama fazla katkısı olmaz dedin, index uygulamak hangi durumlarda gerçek anlamda katkı sağlar yani sorguda kullandığım sıraya bağlı bir şekilde "multiple column index" uygulasam regexp kullanırken pek bir getirisi olmaz mı?

Full text search için farklı işlemler yapmam gerekmiyor mu?Yani ben onu uygulamayı düşünmüş ancak veri girişini yavaşlattığını öğrenince şimdilik askıya almıştım."Full text search kullandığınız için" dediğiniz için bunu soruyorum.

Tekrar teşekkürler...

[BYK]

"Full text search" dediğim bir metnin içinde "herhangi bir yerde, herhangi bir şekilde" bir başka metnin geçip geçmediğini kontrol etmeniz. LIKE kullanıp "%kelime%" yapmak da yine aynı kapıya çıkıyor. Benim bildiğim anlamı bu, yanlışım varsa lütfen düzeltsin gören arkadaşlar

Dizinleme genelde sayısal alanlarda işe yarar. Metin aramalarında da baştan itibaren yapılan aramaları ya da tam oalrak eşleştirmeye dayanan aramaları hızlandırır. Yani "kelime%" ya da "kelime" şeklindeki aramalar dizinleme açık olduğunda daha hızlı olacaktır.

REGEXP güçlü ve esnek oldupu kadar kaynak da tüketen bir sistem olduğu için zorunlu kalmadıkça kullanmamaya çalıştığım bir yöntem(her platformda böyle. MySQL, PHP, JavaScript, Perl vs.). Şu anki durumda istediğiniz sonuca ulaşmak için bunu kullanmanız gerekiyor ya da ilk iletimde belirttiğim alternatifleri deneyebilirsiniz

[mhmtmlh]

Kelimeden önce fazlaca geçen bazı karakterleri seçip bunları da sorguya "OR urunadi LIKE '%-$kelime%' " gibi eklemek bile sanırım regexpten daha iyi bir seçim olacak.Ya da dediğiniz gibi önce hepsini çekip sonra ayıklamak da.

Optimizasyon konusunda bir sorum daha olacak ;
Gelen kelimenin içinde "i" ya da "İ" varsa bunların yerine sırasıyla "ı" ya da "I" getirerek yeni kelimeler üretip onları da "OR LIKE" şeklinde arıyorum, bu replace işlemini

REPLACE('i','ı',urunadi) LIKE '$kelime%'

şeklinde yapmak mı tercih edilmeli.

[BYK]

Açıkçası bu duruma göre değişir ama tablodaki satır sayısı ne kadarsa o kadar metnin içinde değiştirme(replace) işlemi yapılacak ki bu çok iyi bir yöntem değil. Bunun yerine "kelime"nin "ı" ve "İ"'li her türlü versiyonunu çıkartıp sonra sorguya bunları "urunadi LIKE '%versiyon1' OR urunadi LIKE '%versiyon2'..." şeklinde eklemek daha iyi bir çözüm olabilir. Bu yöntemin daha hızlı çalışacağının garantisini veremiyorum ancak daha hızlı çalışması muhtemel.

Kolay gelsin

[mhmtmlh]

Teşekkür ederim @BYK.

[bgul]

Performansi ne kadar artirir bilmiyorum. Garantisini veremem ancak aklima geldi, tartisilasi bi konu bence. Hemen aciklayayim.

Simdi XML'in SQL'e gore daha hizli oldugunu biliyoruz. Eger elimizde XML bir tablo olsaydi, burdan karsilastirmali gitmek cok daha hizli olurdu ki regex kullandiginda performans 2 katina cikiyorsa, muhtemelen cok cok daha kisa surede cozume ulasirdik XML ile. Ancak tum tabloyu XML'e cevirmek bizim isimizi pek gormez. Zira bu sefer MySQL'in isi kalmaz. Madem ki aramaniz sadece "kelime%" seklinde, o zaman ilk harfini alin ve buna gore filtreleyin. Sizin verdiginiz "cek" ornegine bakacak olursak, "c" harfiyle baslayan butun sorgulari alip XML tablosu olusturun. Daha sonra bu tablodan istediginiz gibi olanlari tek tek ayiklayin.

turkce karakter konusunda ise bence urunu tabloya koymadan mutlaka TR karakterlerin HTML karsiliklariyla degistirin: Ş-> & # 3 5 0 ; gibi. Ararken de eger TR karakter varsa, bunu gereken kodla ararsaniz daha saglikli sonuclar cikar.

[BYK]

Belirli durumlarda XML, SQL'den hızlı olabilir ancak veritabanından veriyi çekip ondan XML oluşturup sonra bunun içerisinde aramak yerine XML oluşturmadan bu dizi(array) içerisinde gezip filtreleme yapmak çok çok daha hızlı oalcaktır. Kaldı ki regex kullanıldığında performans değil süre iki katına çıkıyor

[bgul]

kusura bakmayin, yanlis anlamisim