AJAX SEO

[lmcgsgm]

Ben hala bu olayı çözemedim. Şimdi benim istediğim bir anasayfam var
ve hakkımızda iletişim vs. gibi sayfaların hepsi bu sayfa içine ajax
ile çağırılıyor. Ama doğal olarak içerlerinde sadece hakkımızda ve
iletişim içerikleri var. Diyelim ki ben link olayını bir şekilde
çözdüm ve google sitemi http://www.x.com/hakkimizda.asp gibi
indeksledi. Ama hakkimizda.asp içinde sadece içerik var oysaki
anasayfada header var footer var. Bu durumda ne olacak. Bunu nasıl
çözebilirim. Sonra tabi ileri geri butonları sorunu var. Bence ajax
full site için hiç bir zaman kullanılmamalı ama şu anda benden böyle
bir talep var ne yapmalıyım ? :(

[Volkan Özçelik]

Selam,

2009/7/23 lmcgsgm <lmc...@gmail.com>

indeksledi. Ama hakkimizda.asp içinde sadece içerik var oysaki
anasayfada header var footer var. Bu durumda ne olacak. Bunu nasıl

çözebilirim?

Şöyle olabilir:

Öncelikle siteyi hiç ajax kullanmadan tasarlarsın. 

Böylelikle google (ve JavaScript desteği olmayan kişiler) geldiği zaman tüm sayfaları header'lı footer'lı güzel güzel gezer.

Ajax özelliğini sayfa yüklendikten sonra eklersin. Örneğin:

<a href="/Products.aspx" id="LinkProducts">ürünler</a>

linkine JavaScript (ajax) desteği olmadan tıklayan bir kişi (bkz: google) hiç ajax yokmuş gibi ürünler sayfasını görüntüler.

bu linkin onclick olay dinleyicisine de JavaScript tarafında

$( // on dom content ready

var products = document.getElementById("LinkProducts")

products.onclick = myproject.products_click;

);

myproject.products_click = function(evt){

    var content = ajax.get("/ajax/Products.aspx")//kullandığın AJAX kütüphanesine göre burası farklılık gösterir.

    document.getElementById("MainContent") = content.responseText;

};

gibi bir şey yapabilirsin.

Özetle

1. her şeyi AJAX yokmuş gibi yap

2. ardından adım adım AJAX bileşenlerini ekle.

Bu tarz bir mimarinin nasıl oluşturulabileceğinin ayrıntıları için:

[1] Progressive Enhancement http://en.wikipedia.org/wiki/Progressive_enhancement

[2] Graceful Degredation http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/

Yardımcı olması dileğimle,

--
Volkan Ozcelik
+> Front End Architect, MessengerFX : http://www.messengerfx.com/
+> I tweet: http://twitter.com/linkibol
+> linkibol.com - in seek for quality links : http://www.linkibol.com/
+> my blog (in Turkish) : http://www.fikribol.com/donkisot/
+> Sardalya JavaScript Library : http://www.sarmal.com/sardalya/

[Can ÜREK]

Çok teşekkkür ederim. İyi çalışmalar.

[Süleyman Melikoğlu]

Merhaba, benim de bu konuda aklıma takılan bir şey var.

Sayfanın onLoad eventinde (hatta dom yüklendikten sonra) çalışan bir ajax request'im var. Bunu sayfa yüklendikten sonra yapıyorum çünkü pahalı bir veritabanı işlemi olduğu için sayfa açılış hızını yavaşlatmak istemiyorum. Ancak js desteklenmeyen bir browserda bu veriyi nasıl gösterebilirim? Burada arama motoru ya da performans gibi bir sorunla karşı karşıyayım.

"noscript" tagı içinde veriyi yüklemek saçma olacağı için şu anda tek geçici çözümüm şu oldu:
noscript içine "buradaki veriyi yükleyemedim" gibi birşey yazdırıyorum ve bu "açılışta ajax ile yükleme" özelliğini yönetici fonksiyonu olarak site yöneticisine bırakıyorum.

23 Temmuz 2009 14:44 tarihinde Can ÜREK <lmc...@gmail.com> yazdı:

Çok teşekkkür ederim. İyi çalışmalar.

--
Süleyman Melikoğlu
sule...@melikoglu.info
+> A member of Dynamic Four - http://www.dynamicfour.com
+> I'm blogging - http://www.laplacesdemon.com
+> Musical Infection - http://www.last.fm/user/laplacesdemon
+> Tweeting - http://twitter.com/laplaces_demon
+> My band - http://www.lastfm.com.tr/music/The+Sky+We+Scrape
+> My band's myspace - http://www.myspace.com/theskywescrape

[Volkan Özçelik]

Merhaba Süleyman,

Senin durumun "her istediğine sahip olamazsın"a denk geliyor. 

Dolayısıyla olası çözüm de hedef kitlene göre değişiklik gösterecektir. 

Bununla birlikte birkaç öneride bulunabilirim.

Sayfanın onLoad eventinde (hatta dom yüklendikten sonra) çalışan bir ajax request'im var. Bunu sayfa yüklendikten sonra yapıyorum çünkü pahalı bir veritabanı işlemi olduğu için sayfa açılış hızını yavaşlatmak istemiyorum.

• Ne kadar pahalı bir veritabanı işlemi, bunu ölçtün mü? kaç KB veri gönderiyorsun? Bu veri kaç saniyede render ediliyor
• gelen veri XHTML formatında mı, yoksa JSON formatında mı? 
• veritabanı sorgusu optimize edilebilir mi, sorgu ne kadar karmaşık.
• ... sorular arttırılabilir ...

Ölçmeden optimizasyon yapmak, ya da bir sürecin pahalı olduğuna karar vermek doğru olmayabilir.

Kaldı ki, veritabanı işlemin pahalı olsa bile AJAX olsun ya da sayfa içinde olsun her kullanıcı için en az bir kez bu işlemi yapıyorsun; o nedenle net bir performans kazancın yok. Sadece "algı"sal bir kazancın olduğunu düşünüyorsun.

AJAX kullanmak yerine veritabanı işlemini cache'lemek, çok daha hızlı ve çok daha arama motoru dostu bir çözüm olabilir. 

Ancak js desteklenmeyen bir browserda bu veriyi nasıl gösterebilirim? Burada arama motoru ya da performans gibi bir sorunla karşı karşıyayım.

Yine her şey, önceki iletide bahsettiğim "graceful degredation" kavramına odaklanıyor. 

Eğer veri çok büyükse ve "ajax" diye bir şey olmasa ne yaparsın? Veriyi sayfalara bölersin.

kullanıcıya verinin belirli bir kısmını gösterip, veriyi sayfalara bölebilir ve verinin hemen altına 

<< 1 2 3 ... 10 ... 100 >> 

şeklinde bir paging yapısı koyabilirsin.

Eğer istemci AJAX destekliyorsa pagination'ı kaldırır, verinin geri kalanını AJAX ile yüklersin.

Eğer istemci AJAX desteklemiyorsa kullanıcı veriyi sayfa sayfa gezer. 

Hem kullanıcılar, hem de arama motorları mutlu olur :)

"noscript" tagı içinde veriyi yüklemek saçma olacağı için şu anda tek geçici çözümüm şu oldu:

Aslına bakarsan "noscript" tagını kullanma ihtiyacı duymamız, uygulamamızda ciddi erişilirlik eksikliklerinin olduğunu ve tasarımımızı baştan gözden geçirmemiz gerektiğini gösterir [1]

[1] "Six JavaScript Features That We Don't Need Any Longer"

http://www.wait-till-i.com/2005/06/21/six-javascript-features-we-do-not-need-any-longer/

 

Yardımcı olması dileğimle, 

[Mahmut ER]

Merhabalar grubumuz ajax grubu olmasına rağmen ben yinede sormak istedim SQL de paping uygulaması yapan varmı?

kendi sitemde de bununla alakalı bir makale yayınladım sayfalama da göstermek istediğim kadar veriyi çekebiliyorum onda bir sıkıntı yok ama asıl sorun olan gerçekte çektiğim tabloda ne kadar kayıt olduğunu bulamamak....

Dahada detaylandırmam gerekirse örneğin

Öncelikle SQL sayfalamanın performansını araştırmak için 1.000.000 kayıt içeren bir test tablosu oluşturdum. Daha sonra bu test tablosu için bir kaç paging denemeleri yaptım. 


SELECT * FROM

 (
  SELECT
   ROW_NUMBER () OVER (ORDER BY PT_ID) AS ROW_NUMBER, 
   * 
  FROM 
   PRODUCT_TREE_TEST
 ) AS PAGING_TABLE
WHERE ROW_NUMBER BETWEEN 255661 AND 255680




Bu yukarıdaki query de  255661- 255680 arasında olan 20 kayıtı çekebiliyorum,yani ilki startrow ikinci değerde startow+maxrow oluyor...Buraya kadar sorun yok benim için sorun olan ise şu;içteki queryden kaç tane kayıt geldiği bilgisine ulaşamıyorum...Yani çektiğim veriyi küçültmek için güzel bir yöntem de içeridek query'nin kayıt sayısını bilmedikten sonra SQL de paging yapmak için bir anlam ifade etmiyor?Bunu nasıl aşabilirim?Yada daha uygulanabilir bir SQL paging bilen varmı?

---

Windows Live ile fotoğraflarınızı organize edebilir, düzenleyebilir ve paylaşabilirsiniz.

[Volkan Özçelik]

Selam Mahmut,

 

Bunu nasıl aşabilirim?Yada daha uygulanabilir bir SQL paging bilen varmı?

Ayrı bir sorguda kayıt sayısını COUNT ile alabilirsin. 

Masraflı olur diye düşünme. index üzerinde yapılan COUNT oldukça hızlıdır.

Örneğin linkibol 'da link tablosu için

SELECT COUNT(lngLinkID) FROM tblLink

sorgusu

1 rows fetched (10 ms)

COUNT(lngLinkID)

949885

(bu arada ne zamandır count çekmemiştim :) bir milyon linke yaklaşıyormuşuz ya, vay be! )

sonucunu 10 milisaniyede veriyor.

Bununla birlikte

SELECT lngLinkID, strURL FROM tblLink LIMIT 3000,10

gibi 300üncü sayfadan sonraki linkleri getirmek amaçlı bir sorguyu 140 milisaniyede yapıyor. (COUNT'a göre yaklaşık 14-15 kat daha yavaş)

 ...

Bu arada sorgunda SELECT * yapmamaya dikkat et. Hangi kolonlara ihtiyacın varsa onları çek. İhtiyacın olmayan kolonları sorguya dahil etme.

Son olarak ölçmeden optimizasyon yapılmaz. Her iki sorgunun (asıl sorgu ve COUNT sorgusu) ne kadar sürede yapıldığını profile et. 

Eğer beklenmedik şekilde COUNT sorgusu çok uzun sürede sonuç dönmüyorsa tabloyu kontrol et; önemli kolonları endekslemeyi unutmuş olabilirsin.

İlle de tek turda yapmak istiyorsan 

SELECT COUNT(id),  ROW_NUMBER(), ...

deyip sorgunun sonuna

GROUP BY id

ekleyebilirsin. Fakat bu yöntem çok daha yavaş olur diye düşünüyorum (fakat olmayabilir de, SQL engine ne yapmak istediğini anlayıp, tek sorgu yazsan bile ard arda iki sorgu çalıştırabilir -- özellikle sorgunu stored procedure olarak kaydettiysen bu tarz inline optimizasyonlar yapıp execution path'ini değiştirebilyor SQL Server)

Bir not daha: Eğer aksini gerektirecek bir zorunluluk yoksa (ki yoktur) mutlaka stored procedure kullan. stored procedure'ler klasik query'lere göre çok daha performanslıdır.

[Mahmut ER]

Selamlar Volkan öncelikle cevap verdiğin için teşekkür ederim.
2.ci bir sorguda halletmek benimde aklıma geldi ama çalıştığım şirket  http://www.workcube.com/ e-iş ile ilgili web yazılımları geliştiriyor,bunun içinde nerdeyse yok yok,ERP,CRM,LMS,SCM,HR,MRP vs.vs.vs. Durum böyle olunca yazılan querylerde küçük query blokları olmuyor maalesef,kimi yerde 4-5 tablonun birbirine bağlandığı,içinde sub querlerin olduğu havinglerin group by'ların havada uçuştuğu bir çok query ile çalışmak durumunda kalıyorum,böyle bir durumda da içerideki queryinin count'unu almak daha masraflı oluyor,yani SQL açısından dediğin gibi doğru indexleme yapılırsa bir sıkıntı olmaz elbette ancak nerdeyse yazdığım query bloğu kadar daha bir query'i sadece count almak için yazmam gerekiyor buda zaten uzunnn olan query bloğumu biraz daha uzatıyor bu nedenle count almayı hiç düşünmedim zira bizim iş için kod kirliliğini biraz daha arttırır diye düşünüyorum.
LIMIT orneği vermişsin ama sanırım o sadece MYSQL'de çalışıyor maalesef MSSQL de LIMIT yok(yada ben öyle biliyorum :) )
 

---

Date: Sat, 25 Jul 2009 07:08:57 +0300
Subject: [ajaxnedir] Re: SQL PAGING nasıl yapılır bilen varmı?
From: volkan....@gmail.com
To: ajax...@googlegroups.com

[Volkan Özçelik]

Selam Mahmut,

2009/7/25 Mahmut ER <er_mm...@hotmail.com>

e-iş ile ilgili web yazılımları geliştiriyor,bunun içinde nerdeyse yok yok,ERP,CRM,LMS,SCM,HR,MRP vs.vs.vs. Durum böyle olunca yazılan querylerde küçük query blokları olmuyor maalesef,kimi yerde 4-5 tablonun birbirine bağlandığı,içinde sub querlerin olduğu havinglerin group by'ların havada uçuştuğu bir çok query ile çalışmak durumunda kalıyorum.

Acını paylaşıyorum :)
Dur tahmin edeyim.
1. Üzerinde çalıştığınız proje en az 2 senedir geliştirilmeye devam eden, firma içi bir ürün.
2. Senden önce pek çok kişinin koda katkısı olmuş.
3. Bazı yerler "voodoo code" dediğimi "çalışan" ama neden çalıştığını kimsenin bilmediği için kimsenin ellemeye cesaret edemediği,
4. ya da hiçbir şey yapmadığı halde silnirse tüm gökyüzü üzerime yıkılır diye korkulduğundan silinemeyen kod parçaları ile dolu

"kurumsal" bir proje.
 

böyle bir durumda da içerideki queryinin count'unu almak daha masraflı oluyor,yani SQL açısından dediğin gibi doğru indexleme yapılırsa bir sıkıntı olmaz elbette

Ama doğru indeksleme, normalizasyon vb. projenin ilk 6 ayından sonra tarihe karışmıştır :)

Böyle bir durumda kod optimizasyonundan çok donanıma yatırım yapmak daha avantajlı olur (developerlar pahalı bir kaynak; donanım ise göreli olarak ucuz ;) ) -- tabii ben işletme açısından bakıyorum.
 

bu da zaten uzunnn olan query bloğumu biraz daha uzatıyor bu nedenle count almayı hiç düşünmedim zira bizim iş için kod kirliliğini biraz daha arttırır diye düşünüyorum.

Eğer kirli kod kısa zamanda işini gören ve hızlı çalışan kodsa düşünülebilir.
Sonuçta temiz görünen kod, hızlı çalışacak diye bir garanti yok. Hatta aşırı optimizasyon, kod okunurluğunu azaltabilir de.

Ard arda iki sorgu çağırmadan pek de bir çözüm gelmiyor aklıma.

Tek iterasyonda hem resultset'i sınırlandırıp, hem de toplam kayıt sayısını alamazsın bildiğim kadarıyla

Stack Overflow'da şöyle bir makale var:

http://stackoverflow.com/questions/548475/efficient-way-to-make-paging-on-sql-server-2008

benzer şeylerden bahsediyor; ilgini çekebilir.

Bir de şu 4guysfromrolla makalesi var dolaylı ilgili:

http://aspnet.4guysfromrolla.com/articles/031506-1.aspx


Eğer sorgunun satır sayısı çok fazla değişmiyorsa rowcount değerlerini farklı bir lookup tablosunda ya da application değişkeninde cache'leyebilirsin.
 

LIMIT orneği vermişsin ama sanırım o sadece MYSQL'de çalışıyor maalesef MSSQL de LIMIT yok(yada ben öyle biliyorum :) )

Evet :)
MS SQL'de aynı şeyi SELECT TOP ve ROWCOUNT komutları ile yapabiliyorsun.

Gerçi MySQL kullanıyor olsan ve LIMIT kullansan bile limitlediğin veri kümesinin toplam kayıt sayısını alamayacağın için yine SELECT COUNT yapman gerekecekti.

Kolay gelsin,

[Süleyman Melikoğlu]

Merhaba,

MySQL de bu durum için harika bir fonksiyon var. MsSQL için de benzer şekilde bir fonksiyon olabilir:

Öncelikle query'mize SQL_CALC_FOUND_ROWS statementini ekliyoruz. Mesela,

"Select SQL_CALC_FOUND_ROWS * from my_table;"

Daha sonra hesaplanan / bulunan satır sayısını aşağıdaki query ile alabiliyoruz.

"Select FOUND_ROWS() as totalRows;"


Eğer buna benzer bir yöntem kullanamıyorsanız nested querylerden başka bir çözüm yok gibi gözüküyor.



--
Süleyman Melikoğlu
sule...@melikoglu.info

[Süleyman Melikoğlu]

Merhaba Volkan,

Cevabın için teşekkürler. Ajax ile sayfa açılışında yüklediğim veriyi aslında KB olarak veri büyüklüğünden çok algoritmanın NlogN de çalışıp nispeten uzun sürmesi yüzünden pahalı bir operasyon olarak adlandırdım. Algoritmanın yaptığı şey arama motorundan gerekli aramayı yapıp, data mining işlemiyle de ilgili item'ları bulması.

Önerdiğin çözümler kesinlikle mantıklı, özellikle zaten böyle bir sistemi cache yapmadan kullanmamak lazım.

Bu arada bir sorum daha olacak,
Sayfa yüklendikten sonra ajax request'i çalıştırmak yerine Gmail'in yaptığı gibi sayfa girişine bir preloader koymak daha mantıklı mı sizce? Ben kullanıcı olarak sayfanın yavaş yavaş flush edilmesi taraftarıyım. Yani sayfanın içerik bölümü yüklenirken header bölümünü sayfada görmek isterim. Ancak bu konuda kararsızım.


--
Süleyman Melikoğlu
sule...@melikoglu.info

[Mahmut ER]

 İtiraf etmelisin bizim burda önceden çalışanlardansın dimi :P
Valla bu kadar doğru ve güzel bir tespit olamazdı heralde 2002 den geliştirilen bir proje,projeyi geliştirip satıyoruz hatta şu anda 40 yakın müşteri sayısı var, SAP'in vede Oracle'in elinden proje aldığımızda olmuştur :))
Seninde dediğin gibi index sorunu oldukça yaşıyoruz,bizim deyimimizle patlayınca bakıyoruz:)
Çok sağolasın yardımların için gönderdiğin linklerden araştırmaya devam edicem,kal sağlıcakla.

---

Date: Sat, 25 Jul 2009 13:56:25 +0300

Subject: [ajaxnedir] Re: SQL PAGING nasıl yapılır bilen varmı?
From: volkan....@gmail.com
To: ajax...@googlegroups.com

[Volkan Özçelik]

Merhaba Süleyman,

Sayfa yüklendikten sonra ajax request'i çalıştırmak yerine Gmail'in yaptığı gibi sayfa girişine bir preloader koymak daha mantıklı mı sizce?

Bilmem ki...

 

Ben kullanıcı olarak sayfanın yavaş yavaş flush edilmesi taraftarıyım. Yani sayfanın içerik bölümü yüklenirken header bölümünü sayfada görmek isterim. Ancak bu konuda kararsızım.

Ben de bu düşüncedeyim. Önce sayfanın ana iskeletinin yüklenmesi ardından verinin adım adım gelmesi uygulamanın "donup kalmadığı ve çalışmaya devam ettiği" algısını yaratacağı için kullanılırlık açısından daha doğru olur gibime geliyor.

linkibol'da da benzer bir şey yapıyoruz: Önce ana çerçeve yükleniyor; ardından içerik yükleniyor
(yeni linkibol'da bu yapı biraz daha gelişecek -- yeni versiyonun çıkmasına az kaldı; bununla birlikte zaman görelidir tabii ;) )

... tabii ki hangi kullanımın doğru olduğu projeye, kullanım amacına, kullanıcı kitlesine ve içeriğe göre değişir.

Mutlak ve tek bir doğru çözümden bahsedemeyiz.
Gmail'in preloder'ının da bir amacı vardır (ki aklıma birkaç neden geliyor -- bunlardan biri GUI tamamen yüklenmeden kullanıcının GUI ile etkileşmesine izin vermemek mesela)
 

Sevgiler,

[Volkan Özçelik]

Merhaba,

2009/7/25 Süleyman Melikoğlu <monjam...@gmail.com>

Öncelikle query'mize SQL_CALC_FOUND_ROWS statementini ekliyoruz. Mesela,

"Select SQL_CALC_FOUND_ROWS * from my_table;"

SQL_CALC_FOUND_ROWS kullanmak, ard arda 2 sorgu yapmaya göre 10 kat ya da daha fazla yavaş olabilir [1] Dikkatlice test etmeden kullanmamak lazım diye düşünüyorum.

[1] http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Eğer buna benzer bir yöntem kullanamıyorsanız nested querylerden başka bir çözüm yok gibi gözüküyor.

Bildiğim kadarıyla SQL Server'da yani TSQL 'de böyle bir kullanım yok. Bununla birlikte detaylı bir google araştırması da yapmadım. "SQL_FOUND_ROWS alternative sql server 2008" gibi bir google sorgusu daha odaklı çözümler sunabilir.

Sevgiler,

[Orhan Bekdemir]

SELECT

TOP (SAYFADA_LSTELENECEK_KAYIT_SAYISI) ALAN1, ALAN2, ALAN3 FROM TABLO_ADI

WHERE

ID NOT IN(SELECT TOP ((SAYFA_NO - 1) * SAYFADA_LSTELENECEK_KAYIT_SAYISI) ID FROM TABLO_ADI ORDER BY ID) ORDER BY ID

SELECT

@@ROWCOUNT

 

Yaptığın query nin peşine  "SELECT @@ROWCOUNT" sql cümleciğinide eklersen ilk sorgunun sonucunda dönen kayıt sayısını alabilirsin ve işlemini buna göre yaptırabilirsin.

[Volkan Özçelik]

@@ROWCOUNT 'u unutmuşum.

Yanlız yanlış bilmiyorsam @@ROWCOUNT  ile paging yapabilmek için cursor ve temporary table kullanmak gerekebiliyordu -- her ikisi de performansı öldüren ve mümkünse kullanılmaması gereken şeylerdir. Gerçi yanlış hatırlıyor da olabilirim. 

@@ROWCOUNT anladığım kadarıyla MySQL'deki SQL_CALC_FOUND_ROWS ile benzer kullanıma sahip -- dolayısıyla çok geniş veri kümelerinde MySQL'dekine benzer performans sorunlarını da doğruabilir.

@@ROWCOUNT, temp table, ard arda 2 select kullanmak... vb. sorguları SQL Server Management Studio'da "execution plan"larını çıkarıp, inceleyip öyle karar vermek gerekli.

Projeden projeye optimum çözüm değişebilir.

Hatta projenin ilerleyen safhalarında paging tekniğini değiştirmek zorunda kalabilirsiniz.

Şu makale de yararlı olacaktır:

"Paging Large Resultsets in ASP.net"

http://www.codeproject.com/KB/aspnet/PagingLarge.aspx

[Ersin Çalışkan]

Sayfalama işlemi için geçici tablolar kullanabilirsin. Yazıcağın bir sp ye sayfada kac satır olacağını göndererek parametre olarak göndermen ve

Buna göre kaydı temp tabloya yazıp döndürmen gerek.  

 

From: ajax...@googlegroups.com [mailto:ajax...@googlegroups.com] On Behalf Of Orhan Bekdemir
Sent: Monday, July 27, 2009 5:54 PM
To: ajax...@googlegroups.com
Subject: [ajaxnedir] Re: SQL PAGING nasıl yapılır bilen varmı?

 

SELECT

[Volkan Özçelik]

2009/7/31 Ersin Çalışkan <caliska...@gmail.com>

Sayfalama işlemi için geçici tablolar kullanabilirsin.

... bununla birlikte CURSOR ve geçici tabloları mümkün olduğunca kullanmasan daha iyi. 

Yarardan çok zararları oluyor ;)

 

Sevgiler,