Kayıt edilen son verinin idsini almak

insert işleminden sonra kayıt olan verinin idsi gerekiyor.

Select in dışında bunu alabileceğimiz bir komut var mı

mesela şu şekilde

$id = mysql_query("insert into tablo (id,a,b) values (lisanssız,2,3)");

burada lisanssız değerinin yerini alan değeri bir değişkene atıyabiliyormuyuz ?

mysql_insert_id() alir.
Ancak Insert işleminde lisanssız ya da değişken olarak belirtmene gerek yok, auto-increment alanlar zaten otomatik bir sonrakini atar. Bunu zaten bildiğini düşünüyorum, o yüzden belki başka birşey sordun sanırım.

Angelo' Alıntı:

mysql_insert_id() alir.
Ancak Insert işleminde lisanssız ya da değişken olarak belirtmene gerek yok, auto-increment alanlar zaten otomatik bir sonrakini atar. Bunu zaten bildiğini düşünüyorum, o yüzden belki başka birşey sordun sanırım.

Genişletmek için tıkla ...

Sağol Angelo, onu soru kolay anlaşılsın diye yazdım.

"Tabloda ID yok nasıl id olcak" diye geyik çıkmasın diye.

Sağol Atay.

2 kişiye rep atılmıyor Angelo senin kini sonra veririm.

Angelo'ya ben rep verdim senin yerine.

Sorgu ile öğrenmek için;

Aşırı fazla girdisi olan bi tablo için lisanssız değerinden kaçış yok. örn arama motorlarından gelen ref leri kayıt etmek gibi. farklı bir çözüm aramayı dene

selim61' Alıntı:

Aşırı fazla girdisi olan bi tablo için lisanssız değerinden kaçış yok. örn arama motorlarından gelen ref leri kayıt etmek gibi. farklı bir çözüm aramayı dene

Genişletmek için tıkla ...

Yok selim onun gibi değil gelende şöyle kullanımlar için gerekli bana ürün ile birlikte aynı anda ürüne ait 15-20 resim eklene biliyor. Bende her resim için ayrı bir alan açmak yerine ürünlerin resimlerini başka bir tabloda tutuyorum. Böylece sınırsız resim girilebiliyor.

ID UrunAdi <- 1. Tablo

ID UrunId Resim KucukResim <- 2. Tablo

Böyle bir örnektede ilk ürünü giriyorum sonra sql kodu ile son eklenen ürünün id sini aldırıp while la resimleri giriyorum.

Birde şunu sorayım buraya kadar gelmişken.

Şimdi ürünün bir küçük birde büyük resmi var.

ID UrunId Resim KucukResim <- 2. Tablo

bunun gibi tablodamı tutsam daha sağlıklı yoksa Resim ile Küçük Resmin isimleri aynı olsa klasörlerimi farklı olsa iyi olur.

Anlatmak İstediğim
1. Örnek
ID UrunId Resim KucukResim <- Tablo bu resimler resim klasöründe

2. Örnek
ID UrunId Resim <- Tablo bu resimler resim klasöründe küçük resimler küçükresim klasöründe.

IMG'nin src'sinde bir kelime ile halledebileceğiniz bir durum var iken tabloda her küçük resim için bir kayıt tutmanın bence mantıklı bir açıklaması gözükmüyor.

superweb' Alıntı:

IMG'nin src'sinde bir kelime ile halledebileceğiniz bir durum var iken tabloda her küçük resim için bir kayıt tutmanın bence mantıklı bir açıklaması gözükmüyor.

Genişletmek için tıkla ...

Bana da pek anlamsız geliyor ama büyük sistemlerin wordpress opencart vb. hepsi küçük resmide veri tabanında tutuyor. Bu yüzden bende veri tabanında tutuyorum kesin bir bildikleri vardır.

Birde bu wordpress in 2010/10/4 gibi klasörler açmasının nedeni ney ?

Mantıklı açıklaması şu; bugün bir kayıt girdin 278 numaralı ürüne ait resim 278.jpg. buyukresim, kucukresim klasorine 278.jpg yi koydun. Database de tek kayıt var. Yarın bir gün sadece küçük resmi değiştirmek istersen, küçük resmi upload ettiğin gibi büyüğünü de rename etmelisin, çünkü isimlerini birbirlerine bağladın. Özellikle çok ürünlü sistemlerde bu esnekliğe ihtiyaç var. Biz çoğu zaman küçük resimleri sonradan değiştirebiliyoruz, tıklama oranlarına göre, küçük resimi daha bir zoom in versiyonuna çeviriyoruz vs. Büyük resmi oynamaya gerek kalmıyor.

Angelo' Alıntı:

Mantıklı açıklaması şu; bugün bir kayıt girdin 278 numaralı ürüne ait resim 278.jpg. buyukresim, kucukresim klasorine 278.jpg yi koydun. Database de tek kayıt var. Yarın bir gün sadece küçük resmi değiştirmek istersen, küçük resmi upload ettiğin gibi büyüğünü de rename etmelisin, çünkü isimlerini birbirlerine bağladın. Özellikle çok ürünlü sistemlerde bu esnekliğe ihtiyaç var. Biz çoğu zaman küçük resimleri sonradan değiştirebiliyoruz, tıklama oranlarına göre, küçük resimi daha bir zoom in versiyonuna çeviriyoruz vs. Büyük resmi oynamaya gerek kalmıyor.

Genişletmek için tıkla ...

Küçük, orta, büyük, çok büyük resimleri ayrı ayrı, sadece birini veya hepsini değiştirmek için upload ettikten sonra isimlerini eski isimleri olarak kaydetmeyip de neden yeni isim vermek zorunda kalıyorsunuz?

Resimleri isimlendirmek için belirli bir prosedür oluşturulması gerekli zaten. Upload ettiğim isimle kaydedemem. Elimde 7083.jpg diye bir dosya var diyelim. Zaten o dosya daha önceden varsa, yeniden isimlendirmek gerekiyor 7083-1.jpg vb. Biz bunu tercih etmediğimiz için her resmi, ürün adı / stil kodu . jpg şeklinde numaralandırıyoruz. Fonksiyon bu şekil olunca, ürün isimleri de gelecekte değişebilir olduğundan çok sık olmasa da yeni upload edilen resimlerin isimleri öncekilerinden farklı olabilir. Ha databaseden okuyup, üstüne yazabilirim aynı şekilde, ama seo/standardizasyon açısından her yeni resim, aktif ürün ismine göre isimlendiriliyor. Bizim nedenimiz bu. Eminim başka insanların başka sebepleri vardır. Sonuç olarak veritabanına getirdiği ekstra yük bir çok insan için getirdiği esnekliğın yanında önemsenmeyecek boyutta kalıyor. Bu yüzden %99 shopping cart da bu şekilde kodlama tercih edilmiştir bence.

Ürün ismi aktif ürüne göre değişiyor diyorsunuz, o zaman bu zaten yeni bir ürün oluyor. Eğer ürün satışını yeni ürün ekleyerek değilde sadece ürünlerin ismini değiştirerek yapıyorsanız eski ürün ile ilgili bilgileri de (satış, gösterim, yorum, vs.) kaybediyorsunuz (hepsi yeni ürün adına kayıtlı imiş gibi oluyor). Yeni ürün eklemesi yapıp eski ürünü satıştan kaldırsanız veya kaldırmayacaksanız da artık satılmıyor demeniz daha iyi olmaz mı?

Hayır, mesela bugün ürün sisteme giriliyor Janjanlı Bikini Seti diyelim, daha sonra bu ürünün ismi Alaboralı Bikini Seti olarak değiştiriliyor o veya bu sebebten dolayı. Sadece name field i değişiyor, id, satışlar, yorumlar herşey aynı. Yeni resim upload edildiğinde fonksiyon name'i çektiği için değişik oluyor. Eminim üzerine uzun süre düşünülse daha fazla neden de ortaya çıkacaktır gerçek hayatta karşılaşılan problemler bu konuda. Ama kanun değil tabi ki, obur türlü yapmak istiyorum diyene yapma sakın denecek kadar ciddi bir problem değil, kişinin isteğine bağlı

Karşılıklı fikir alışverişi biraz dallanıp budaklandı; konuştuklarımızdan gördüğüm kadarıyla ortada birkaç durum var;

-Ürün resimlerinden birini değiştirmek;
Ürün resimlerinden birini değiştirirken eski resmi silmek (silmek istenmiyorsa farklı klasöre taşınabilir) ve yeni resmi eski resim isminde kaydetmek.

Sadece name field i değişiyor, id, satışlar, yorumlar herşey aynı.

Genişletmek için tıkla ...

-Ürün adını değiştirmek;
Ürün adını değiştiriyorsak zaten ürünün tüm resimlerinin isimlerini değiştirmek zorundayız. Veritabanında tutsak da tutmasak da (Resim seosu düşünüldüğünde)

Sadece name field i değişiyor, id, satışlar, yorumlar herşey aynı. Yeni resim upload edildiğinde fonksiyon name'i çektiği için değişik oluyor.

Genişletmek için tıkla ...

-Ürün adını değiştirmek bunu yaparken de bu yeni isimde resim eklemek;
Ürün adını değiştirirken yeni resim eklendiğinde yeni resim yeni ürün isminde, eski ürün isimlerini taşıyan resimler zaten yenisi ile değiştirilmek zorunda (yine resim seosu düşünüldüğünde) (Ben bu noktada sadece resim isimleri değiştirilmesi kanısındayım. Ekstra veritabanına dokunmadan)

Ayrıca;

Hayır, mesela bugün ürün sisteme giriliyor Janjanlı Bikini Seti diyelim, daha sonra bu ürünün ismi Alaboralı Bikini Seti olarak değiştiriliyor o veya bu sebebten dolayı.

Genişletmek için tıkla ...

Zaten resim isimlerini (resim seosu düşünüldüğünde) ürün isimlerinden yola çıkarak adlandırıyorsak sadece 1 field bize yetmetecek mi? (ürün resminin ismini bastığınızda her seferinde ingilizce karaktere ve url kriterlerine dönüşümü yapmak istemiyorsak, istiyorsak o field e de gerek yok ürün ismi zaten resim ismi oluyor.)

Ürünün bir veya daha fazla resmi olduğunda zaten her ayrı resim ismini veritabanında tutacağız. Fakat aynı resmin büyük|küçük|orta vs. versiyonlarının ayrı ayrı fieldlerde tutmanın fuzuli olduğunu kanısındayım.

Dediğiniz gibi her programcının bir kod yazışı var, kimse kimseyi birşeye zorlayamaz. Can sıktım ise affola.

Can sıkılacak bir durum yok. Zaten ben biz bu yolla yapıyoruz, database'de tek field e indirgersek yapılamaz demedim. Yapılır, kod yapısı değiştirilir ve buna uydurulur. Ama yapı tercihe göre bu şekilde yapılmış, ben bizim açımızdan ilk aklıma gelen nedeni söyledim. Volusion, open cart gibi uygulamalar senelerdir deneme/yanılma kullanıcı isteği bir sürü etkene göre şekillendiği için, eminim herkesin bunu istemek için geçerli bir nedeni vardır.

Bugün kendime hızlıca 50-60 ürünlük bir e-ticaret sitesi kuracak olsam büyük ihtimalle tek field yapıp, kodda baktığı dizini değiştiririm. Ancak 20-30 bin ürünlü büyük siteler için oluşabilecek iş problemlerinde bu esnekliği en baştan vermenin bize bir zararı olmadı.

Sonuçta ürün tablosuna, resim1, resim2, resim3, resim4 diye alan açan bir çok uygulama da gördüm. Onlar çalışmıyor mu? Çalışıyor. Ama herkesin tercihi farklı tabi.

Ya benim kafam iyi olmuş ya da okuduklarımı yanlış anlıyorum. (İkisi de aynı şey ama olsun.)

Burada

Bugün kendime hızlıca 50-60 ürünlük bir e-ticaret sitesi kuracak olsam büyük ihtimalle tek field yapıp, kodda baktığı dizini değiştiririm. Ancak 20-30 bin ürünlü büyük siteler için oluşabilecek iş problemlerinde bu esnekliği en baştan vermenin bize bir zararı olmadı.

Genişletmek için tıkla ...

"20-30 bin ürünlü siteler için tek field yapmadık." diyorsunuz.

Burada da

Sonuçta ürün tablosuna, resim1, resim2, resim3, resim4 diye alan açan bir çok uygulama da gördüm. Onlar çalışmıyor mu? Çalışıyor. Ama herkesin tercihi farklı tabi.

Genişletmek için tıkla ...

"Çok fieldli uygulamalar var çalışıyor ama bu kötü birşey." diyorsunuz.


Ben de zaten diyorum ki çok fieldli olmasın, resimler tablosunda tek field olsun. Yani bence yukarıdaki "ürün tablosuna resim1, resim2, resim3.." yapısı ile "resim tablosu ; urun_id, resim_buyuk, resim_orta, resim_kucuk vs." arasında bir fark yok. İkisi de tu kaka.
Neyse sabah yazdığınızı yine okuyayım.

http ://g-ecx.images-amazon.com/images/G/01/kindle/shasta/photos/US-WIFI-PT07-thumb._V188702420_.png
http ://g-ecx.images-amazon.com/images/G/01/kindle/shasta/photos/img_beach-doug-01._V188696048_.jpg

http ://g-ecx.images-amazon.com/images/G/01/kindle/shasta/photos/big-viewer-3G-01-lrg._V188696038_.jpg

http ://g-ecx.images-amazon.com/images/G/01/kindle/shasta/photos/big-viewer-3G-01-small._V188696032_.jpg

http ://ecx.images-amazon.com/images/I/51uBIKbtF6L._SY110_.jpg
http ://ecx.images-amazon.com/images/I/71G1fOAerqL._AA1000_.jpg

superweb bende ilk başlarda senin gibi düşünüyordun ama o sistemi kullanan benden başka hiç bir site bulamadım. Tabi baktığım siteler ufak tefek siteler değil. Mesela yukarıdaki amazon resimleri aynı klasörde ama isimleri farklı bunları veri tabanında tutmasa bulamaz. Bende bu siteler gibi yapıyorum.

Amazonun daki bir ürünün;

http://ecx.images-amazon.com/images/I/71oLeP01cHL._AA1500_.jpg Büyük resim.
http://ecx.images-amazon.com/images/I/41gzCKUDrAL._AA50_.jpg Küçük resim.

Resim seosu gereksiz veya sisteme o kadar yük ve içinden çıkılmaz problemler getiriyor ki amazon resimlerde seo düşünmemiş, yapmamış.

Derdimi anlatabilsem öğretmenliğimi yapardım. Maalesef o yetenek bende yok.