poate am folosit nepotrivit termenul framework (influentat de laravel), insa daca alege drupal baza de date o sa aiba o structura specifica drupal, care e diferita de cea wordpress (daca alege asa ceva) si care o sa fie diferita de ce si-ar construi cu laravel.
1 Like
Rescriu…
Este nevoie de cineva cu experienta in design baze de date.
Vorbim despre partea de produse, produse cu variatii. Un exemplu real este catalogul de produse al Pizzahut.
Daca este cineva disponibil… dati un pm.
Salut John
Tu esti pe principiul: hai sa adaugam si aia, sigur trebuie sa fie bine.
Wordpress nu este framework. Eu incerc sa tin discutia in jurul topicului.
Problema este relativ simpla… am si rescris-o in postarea anterioara.
faci presupuneri despre principiile mele la fel cum faci despre timpul necesar unui dev sa iti rezolve taskul (oare asta sa fie un motiv pentru care nu sunt doritori?).
poate nu trebuia sa raspund si cu offtopic la alt offtopic.
poti sterge daca incurca.
am spus mai sus, construiesc chestii care vand online de multi ani (se numara in decenii deja), doar ca nu cu laravel.
imi scapa locul in care afiramtia ta se leaga de realitatea mea.
foarte bine
Eu am urmărit subiectul și eram interesat de provocarea asta. În primul rând pentru că, în general, mai nimeni nu caută lucruri create de la 0, custom. Ori eu cam asta fac. Eram interesat până să văd că din punctul lui de vedere e o chestiune de 30 de minute.
Cred că mi-ar lua 30 de minute să explic în scris, corect, ce se întâmplă în baza de date. Dacă el crede că ar fi de lucru 30 de minute pentru crearea structurii bazei de date, atunci și eu cred că i-ar lua lui o oră sau două să creeze API-ul prin care se va comunica cu baza de date. Și sper că îl face de la 0, așa cum și eu aș face schema plecând de la nimic.
Dacă crede că durează 30 de minute, îmi imaginez că intenționează să plătească pentru 30 de minute. Corect ?
În sfârșit. O întrebare. Laravel Eloquent poate comunica cu o bază de date mysql ?
Este un orm. poate comunica cu orice baza de date
1 Like
in principiu, cam in toate frameworkurile mari din php, un api care sa faca chestii banale se face extrem de repede. sa aduci toate intrarile dintr-o tabela, cateva secunde. sa aduci produsele in functie de anumite filtre, cateva minute. daca ai db-ul gandit cum trebuie, operatii de genul asta sunt extrem de usor de implementat.
ps: am facut ceva asemanator acu cativa ani cand incepeam sa ma joc cu laravel. daca mai gasesc proiectul o sa pun aici structura db-ului.
Table: Categories
| id | name |
|----|----------|
| 1 | Clothing |
| 2 | Shoes |
| 3 | Electronics |
Table: Products
| id | name | category_id |
|----|------------|-------------|
| 1 | T-Shirt | 1 |
| 2 | Jeans | 1 |
| 3 | Sneakers | 2 |
| 4 | Smartphone | 3 |
Table: Sizes
| id | name |
|----|-------|
| 1 | Small |
| 2 | Medium|
| 3 | Large |
Table: ProductSizes
| product_id | size_id |
|------------|---------|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
| 2 | 1 |
| 2 | 2 |
| 2 | 3 |
| 3 | 1 |
| 3 | 2 |
| 3 | 3 |
Table: Addons
| id | name | size_dependent |
|----|-----------|----------------|
| 1 | Embroidery| true |
| 2 | Engraving | true |
| 3 | Gift Wrap | false |
Table: ProductAddons
| product_id | addon_id | size_id |
|------------|----------|---------|
| 1 | 1 | 1 |
| 1 | 1 | 2 |
| 2 | 2 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | null |
| 4 | null | null |
2 Likes
inteleg ca stocul poate nu e relevant, dar pretul?
apoi… o pizza are pe langa marime… si tipul blatului variabil (si astea sunt disponibile in functie de marime).
addonurile alea (toppingurile) au si ele preturi care depind de celelalte caracteristici (in special marime).
de reguli / restrictii de combinare nu mai zic.
o pizza dev xxl va avea un sku diferit fata de o pizza dev xl. pe nir n-o sa-ti apara ca ai comandat 10 pizza dev, o sa-ti apara ca ai comandat 3 xxl si 7 xl. la fel si cu stoc-ul, daca vrei sa-l tii, deja se complica treaba.
tu vrei sa o prezinti clientului ca pizza dev si el sa-si aleaga dimensiunea.
practic, in tabela products vrei sa-ti tii informatii care sa reprezinte cat mai bine produsul (nume,stoc total, sku, …), o alta tabela care sa reprezinte exact ceea ce vinzi tu si inca o tabela pt variatii care sa aiba legatura cu produsul original.
products
| id | name | sku |
============================
| 1 | pizza dev xxl | 0001 |
| 2 | pizza dev xl | 0002 |
| 3 | papuci rosii m 42 | 0003 |
sku-ul poate sa fie intern sau direct de la furnizor.
products_pe_care_le_afisez_pe_saitul_mieu
| id | name | price?|
=====================
| 1 | pizza dev | 5 |
| 2 | papuci | 10 |
attributes
| id | name |
| 1 | size |
| 2 | color |
products_variants
| id | name | product_id | attribute_id | price? |
======================
| 1 | xxl | 1 | 1 | 5 |
| 2 | xl | 2 | 1 | 3 |
| 3 | rosu | 3 | 2 | 10 |
| 4 | 42 | 3 | 1 | 10 |
asta-i doar un exemplu de baza, in functie de ce ai nevoie (stocuri, furnizori, pret de achiztie, etc) se poate complica.
Ceva next level sunt cei de la UberEats, sa vezi acolo :))
Culmea e că am făcut mai demult o aplicație de la 0 pentru o firmă de catering.
Era și rețetar inclus acolo, n-a fost ușor, dar nici rocket science.
Îți trebuie o schemă destul de solidă să gestionezi și stocurile până la urmă.
Acest subiect a fost închis automat după 30 de zile de la primul răspuns. Nu mai sunt permise răspunsuri noi.