mgsmus Size bir tüyo daha vereyim. Siparişleri orders tablosunda tek bir sipariş olarak tutmayın. orders tablosunda ana siparişi tutun. suborders gibi bir tabloda normal siparişi tutun, tutarı vs ile birlikte. Bu şekilde yaparsanız parçalı sipariş özelliği kullanabilirsiniz. Örneğin Migros’ta bir sipariş veriyorsunuz, sipariş gelmeden sepete ekleme yapabiliyorsunuz. Diyelim ki Pazartesi sipariş verdiniz, Çarşamba teslim edilecek. Salı günü sepete 2 ürün daha ekleme yapıyorsunuz. Migros mevcut siparişi değiştirmiyor, 2 üründen yeni bir sipariş daha oluşturuyor ama her iki siparişi de tek bir sipariş altında gösteriyor. Böylece bekleyen siparişteki ürün değişiminde örneğin kampanyalardan çıkacak sorunların önüne geçiyor.

hocam konuştukça kafamızı açıyorsunuz vallahi böyle şeyleri nasıl öğreniyorsunuz ? Githubta gitlabta yapılan projeleri oturup inceliyorum sizin bu anlattığınız sku sistemini uygulayan görmedim. Hani kendimizi geliştirmek için kod okumaya özen gösteriyorum ama böyle şeyleri sanıyorum kurumsal bir firmada ihtiyaç olmadan anlayamacağım., Birde şurda kafam karıştı

Migros’ta bir sipariş veriyorsunuz, sipariş gelmeden

Biz zaten kartta yani sepetimde tutuyoruz ürünü müşteri onaylayana kadar bekliyor ki 2 gün içerisinde stok biterse işlem yapamıyor haliyle. Burda ki sipariş gelmeden ki kasıt nedir hocam ? Tamamlanan Her siparişin kendi idsi var,2 siparişide tamamlarsa idleri farklı,istediğimizdan iade yapabiliyoruz. Biz mi yanlış kurguladık acaba diye bir düşünmedim değil Birde tablo yapısına yukarıda ki gibi örnekle açıklayabilirseniz çok sevinirim. Saygılarımı sunuyorum

kartal Siz Migros'tan sipariş verince teslimat tarihi seçiyorsunuz. Ön otorizasyon ile paraya bloke koyuyor. Teslimat tarihine belli bir süreye kadar sepete ekleme çıkarma yapmanıza izin veriyor. Ekleme yaparsanız onu alt sipariş olarak kaydediyor fakat o da ana sipariş altında yer aldığı için aynı anda teslim ediliyor. Ekleme yaptığınız ürünleri ayrıca ödemenizi istiyor, onun ödemesi de ayrı yapılıyor. Teslim edilinceye kadar sipariş tamamlandı sayılmıyor. Teslim edilince kartınızdan, bloke edilen tutardan sipariş tutarı kadar çekilip kalanı bırakılıyor yani provizyon satışa çevriliyor. Ekleme yaptıysanız o ek siparişin de aynı şekilde provizyonu satışa çevriliyor. Sipariş o zaman tamamlandı oluyor. Bu market olduğu için ona göre dizayn edilmiş, o yüzden klasik eticaretten farklı. Örneğin sepete attığım ürün yoksa alternatifini getir diye bir seçenek var. Bazı durumlarda stokda gözükse bile ürün olmayabiliyor, hasarlı çıkması gibi sebeplerden ötürü. O seçeneği işaretlediyseniz aynı ürünün başka markasını getiriyorlar. Eğer o ürün diğerinden pahalı ise elbette sipariş tutarı artıyor. Bunun sorun olmasını engellemek için de Migros'tan alışveriş yaptığınızda aslında kartınızda sipariş tutarından daha fazla ücrete bloke koyuyor. Örneğin 100 TL'lik alışveriş yapınca 110 TL bloke koyuyor. Sipariş, ürünün fiyatı değişmesi durumunda 105 TL'ye çıkmışsa 110 TL bloke içinden 105 TL'si alınıyor. Böylece ek ödeme çıkmıyor. Diğer bir olay da Migros'ta siparişi ileri bir tarihe erteleme var, şu gün getir diye. Öyle yaptığınızda o günün fiyatları ile siparişiniz toplanıyor. Yani Pazartesi 100 TL olarak verdiğiniz sipariş Cuma günü size 102 TL olarak gelebilir. Elbette bunda hiçbir sıkıntı yok çünkü üye olurken bu şartları kabul etmiş oluyorsunuz. Bunun gibi farklı sektörlerdeki eticaretlerde çok fazla değişen durum var, işini yaptığınız sektöre göre kurgulamalısınız. Bu iş sadece sepete at, öde, bekle olayı değil.

Tablo yapısı da sanırım ek sipariş olayını soruyorsunuz, kabaca şöyle:

orders
+----+---------+---------------------+
| id | user_id |     order_date      |
+----+---------+---------------------+
|  1 |       1 | 2020-06-27 10:00:00 |
+----+---------+---------------------+

suborders
+----+----------+-------+---------------------+
| id | order_id | total |     order_date      |
+----+----------+-------+---------------------+
|  1 |        1 | 20.00 | 2020-06-27 10:00:00 |
|  1 |        1 | 53.75 | 2020-06-27 12:30:00 |
+----+----------+-------+---------------------+

@mgsmus hocam, şimdi mysql'de yaptığımız sorgularda grup olarak nasıl arayabiliriz. Yaptığım sisteme göre SKU numarasını ilişkileri tutan tablodan alıyorum, bunu bir türlü çözemedim.

Örneğin verilerimiz:
gelen_veri
veri array veya herhangi bir şekilde post olarak da gelebilir. Ancak nitelik_Id = 1 tanim_Id = 2 ve nitelik_Id = 6 tanim_Id = 7.
Mysql sorgu sonucu ile yukarıda ki kriterlere tam olarak uyan SKU alacağım. Aşağıda ki tabloya göre 1 numaralı ürüne ait SKU1 dönmeli.

urun_sema
Id - urun_grup - nitelik_Id - tanim_Id - urun_Id - SKU
1 - urun_grup - 1 - 2 - 1 - SKU1
2 - urun_grup - 6 - 7 - 1 - SKU1
3 - urun_grup - 1 - 2 - 1 - SKU2
4 - urun_grup - 6 - 8 - 1 - SKU2
5 - urun_grup - 1 - 2 - 1 - SKU3
6 - urun_grup - 6 - 9 - 1 - SKU3
7 - urun_grup - 1 - 3 - 2 - SKU4
8 - urun_grup - 6 - 7 - 2 - SKU4
9 - urun_grup - 1 - 3 - 3 - SKU5
10 - urun_grup - 6 - 4 - 3 - SKU5

kadirakkus9 Tablo isimlendirmeleriniz çok karışık ve bazı yerler farklı olmuş. Aslında farklı bir cevap yazacaktım ama sildim. Ben size temel tabloları yazayım:

categories
Ürün kategorileri.

+----+-----------+-----+-----+-----------+
| id | parent_id | lft | rgt |   name    |
+----+-----------+-----+-----+-----------+
|  1 |           |   1 |   6 | Erkek     |
|  2 |         1 |   2 |   5 | Giyim     |
|  3 |         2 |   3 |   4 | Üst Giyim |
+----+-----------+-----+-----+-----------+

Burada Nested Set veri yapısı kullanılıyor, forumda aratabilirsiniz. Örneğin bu tabloya göre Erkek kategorisinin içinde hangi kategoriler var derseniz (ve Erkek kategorisini de sonuca dahil ederseniz)

SELECT *
FROM categories
WHERE lft >= 1
  AND rgt <= 6
ORDER BY lft

şeklinde sorgu atılır. Bu sorgu size şunu döner:

  1   Erkek      
  2   Giyim      
  3   Üst Giyim  

ve mesela şunu yapmanıza olanak tanır:

Erkek > Giyim > Üst Giyim 

Bu yapıyı Laravel'de kolayca kullanmak için şu paketi kullanıyorum:
https://github.com/lazychaser/laravel-nestedset

Yapıyı resimle anlatmak gerekirse (lft ve rgt nedir mesela):

products
Ana ürünler

+----+---------+
| id |  name   |
+----+---------+
|  1 | T-Shirt |
+----+---------+

product_categories (pivot)
Hangi ürün hangi kategoride

+------------+-------------+
| product_id | category_id |
+------------+-------------+
|          1 |           3 |
+------------+-------------+

attributes
Ürün özellikleri

+----+-------+
| id | name  |
+----+-------+
|  1 | Beden |
|  2 | Renk  |
+----+-------+

attribute_values
Özellik değerleri

+----+--------------+---------+------+
| id | attribute_id |  name   | code |
+----+--------------+---------+------+
|  1 |            1 | S       | S    |
|  2 |            1 | M       | M    |
|  3 |            2 | Kırmızı | KRM  |
|  4 |            2 | Mavi    | MVI  |
+----+--------------+---------+------+

product_attributes (pivot)
Hangi ürün hangi özelliğin hangi değerine sahip. Bu tabloya göre T-shirt, S beden ve kırmızı renge sahip

+------------+--------------+----------+
| product_id | attribute_id | value_id |
+------------+--------------+----------+
|          1 |            1 |        1 |
|          1 |            2 |        3 |
+------------+--------------+----------+

variants
Ürünler/Varyantlar/Varyasyonlar...

+----+------------+-------------+-------------------------+
| id | product_id |     sku     |          name           |
+----+------------+-------------+-------------------------+
|  1 |          1 | 1-S-KRM     | Kırmızı S Beden T-Shirt |
+----+------------+-------------+-------------------------+

shops
Dükkanlar/Şubeler. Neden böyle bir tablo var derseniz sebebi product_stock tablosunda yazıyor:

+----+-----------------+
| id |      name       |
+----+-----------------+
|  1 | Kadıköy Şube    |
|  2 | Beylikdüzü Şube |
+----+-----------------+

product_stock (pivot)
Ürün stokları tablosu. Birden fazla şube vs olabileceği için her ürün her mağazada farklı stokta ve nadiren de olsa farklı fiyatta yer alabilir. O yüzden ayrı tabloda tutulması mantıklı (Tabloya göre Beylikdüzü mağazasında Kırmızı S beden t-shirt stokta kalmamış)

+---------+------------+------------+----------+-------+
| shop_id | product_id | variant_id | quantity | price |
+---------+------------+------------+----------+-------+
|       1 |          1 |          1 |       17 | 29.95 |
|       2 |          1 |          1 |        0 | 29.95 |
+---------+------------+------------+----------+-------+

Senaryo:

• Kullanıcı ürün detay sayfasına geldi. product_id=1 yani hangi ürün olduğunu biliyoruz.
• Hangi ürün olduğunu bildiğimiz için product_attributes tablosundan product_id=1 olan özellikleri alıp ekrana gösterdik. Detay sayfasında şimdi sırasıyla Beden ve Renk gösteriyoruz.
• Bu beden ve renk altında attribute_values tablosunda yer alan değerleri gösteriyoruz ama bunu yaparken sadece product_attributes içinde yer alan value_id'lerine göre listeletiyoruz. Yani beden altında S; renk altında ise sadece Kırmızı listelendi.
• Kullanıcı S seçti, Kırmızı seçti. S'nin kodu S, Kırmızının kodu KRM, product_id ise 1. Şu an aslında SKU kodunu tekrar oluşturmam için tüm veri var. Hepsini - ile, sırasını bozmadan birleştirince 1-S-KRM elde ettim.
• Elde ettiğim bu 1-S-KRM kodu ile variants tablosuna where sku = '1-S-KRM' şeklinde sorgu atarak seçilen özelliklere denk gelen varyantı buldum.
• Sepete ekledim.

Bu varyant elde etmenin başka yolları da var. Herkes kendi sistemine, tablo yapısına göre kodluyor. Sizin VaryasyonSecenekID olayı mantıklı, kullanabilirsiniz. Örneğin şöyle bir pivot tablo da tutulabilir:

variant_attribute_values

+------------+----------+
| variant_id | value_id |
+------------+----------+
|          1 |        1 |
|          1 |        3 |
+------------+----------+

ya da product_attributes tablosuna variant_id eklenebilir.

SKU kodu otomatik oluşan bir kod olmalı ve tersten tekrar oluşturulabilmeli. Bu kod müşterinin gireceği bir kod değil. Varsa öyle bir kod, barkod gibi, onu ayrı bir alanda tutmalısınız.

kadirakkus9 Stoğu sizin yaptığınız gibi varyant tablosunda tutuyorsanız varyanta ulaştınız mı zaten stocğa da ulaşmış oluyorsunuz. Benim dediğim gibi product_stock kullanırsanız shop_id ve variant_id ile o tabloya sorgu atacaksınız.

kadirakkus9 Anlattığınız Sistemde İlerde Karşımıza Çıkabilecek Herhangi Bir Sorun Var mı ?

Kesinlikle Öyle Bir Şey Söz Konusu Olamaz, Garantisi Bizzat Şahsım. Bunu 4 Kişiye Daha Anlattım, Biri Hepsiburada’yı, Diğeri Trendyol’u, Bir Diğeri De Gittigidiyor’u Kurdu. 4. Kişi Bu Bana Pek Uymadı Dedi, O Da Nevzat Tabi ki sorun vardır, siz ilerledikçe karşınıza çıkar, ben sadece kitabın önsözünü yazdım size.

Merhaba @mgsmus discount_price alanını product_stock tablosuna mı eklemek mantıklı yoksa product_discounts adında tablo açmak mı daha efektif bir kullanım olur.2. sorumda kategoride lft ve rgt migration ile biz ekliyoruz dime(nested ile bir alakası yok) lft ve rgt create ederken nasıl bir mantık ile değerlerini veriyoruz.
3.sorum ürün url slug ile aratacağım . ürünün slug vartiantta mı tutulmalı

echo75 İlk sorunuza cevap veremiyorum, 9 ay önce konuşulmuş bir konu, konuyu incelemem lazım.

İkinci sorunuzun cevabı ise, ilk kategorinin left değeri 1, right değeri 2 oluyor. Aynı seviyede bir kategori ekleyeceğiniz zaman yeni kategorinin değerleri bir öncekinin left+1, right+1 oluyor. Eğer ilk kategorinin altına bir kategori ekleyecekseniz oradaki değerleri bulup +2 ekleyerek yer açıyorsunuz ve araya ekliyorsunuz. Şöyle mesela:

SELECT @newrgt := rgt,
       @newparentid := 1
FROM   categories
WHERE  id = 1;

UPDATE categories
SET    rgt = rgt + 2
WHERE  rgt > @newrgt;

UPDATE categories
SET    lft = lft + 2
WHERE  lft > @newrgt;

INSERT INTO categories
            (name, parent_id, lft, rgt)
VALUES      ('Alt kategori', @newparentid, @newrgt + 1, @newrgt + 2); 

Kısa yolu olan bir şey değil yani. Her seferinde değerlerin baştan hesaplanması gerekiyor. Ekleme, silme ve taşıma işlemleri için.

Üçüncü sorunuzun cevabı evet, slug varyantta tutulacak çünkü sattığınız ürün o. Ana ürünün görevi sadece gruplama gibi işlemler.

mgsmus Öncelikle geri dönüşünüz için çok teşekkür ederim.
+----+-----------+-----+-----+-----------+
| id | parent_id | lft | rgt | name |
+----+-----------+-----+-----+-----------+
| 1 | null | 1 | 6 | Erkek |
| 2 | 1 | 2 | 5 | Giyim |
| 3 | 2 | 3 | 4 | Üst Giyim |

| 4 | null | 1 | 6 | Elektronik|
| 5 | 4 | 2 | 5 | Bilgisayar|
| 6 | 5 | 3 | 4 | Laptop |
+----+-----------+-----+-----+-----------+

Erkek ve Elektronik eklendim. Eleltronik için lft değerleri 1,2,3 mü olmalı yoksa. Erkek,Giyim,Üst Giyim lft degeleri 1,2,3 üzerinden devam edip 4,5,6 mi olmalı orayı tam anlayamadım
Product_discount içinde variants tablosuna discount_id ekledim. product_discounts diye bir tablo açtım bu konuda da müsait olduğunuzda geri dönüşünüzü bekliyorum. Teşekkü ederim

Ürün varyasyonuna göre resim tablosu nasıl olmalı
varyant images adında tablo oluşturup variyants id ile mi ilişkilendirmeli Yani

id--------images_name-------------varyants_id

1--------beyaz-t-shirt-1-.jpeg--------1
2--------beyaz-t-shirt-2-.jpeg--------1
3--------sari-t-shirt-1-.jpeg--------2
4--------sari-t-shirt-2-.jpeg--------2

Resimler varyant tablosunda da tutulabilir ama bir ürünün renk dışında da varyasyonları olabileceği için null alanlar çok olabilir.
Değişik renkte ki ürüne ait her renk için örnek 3 resim olsa
2 renk x 3 = 6 resim.
Ama beden vb. attribute değerlerinde resim olmayabilir.

Sizce doğrumu tablo yapım.