Este vorba despre baza de date al unui webshop
Scopul principal este de a gasi un design bun, prin care baza de date poate fi consumata de catre Laravel Eloquent
Subiectele importante sunt comenzile si produsele. Produsele sunt putin mai complexe, cu variatii si alte nebunii.
Salutare !
Poti sa ne dai mai multe detalii de ce ai avea nevoie de o chestie custom pentru asta ? Ce business logic vrei sa implementezi, ce limitari ai gasit la tehnologiile actuale pentru webshop-uri.
Ce scop are acest proiect ?
Nu vreau sa ma complic prea mult… am gasit ceva pt Laravel - https://aimeos.org/
Stiti / ati folosit ceva asemanator?
Eu am nevoie sa creez un API care este consumat de catre o aplicatie de mobil, respectiv: Se listeaza produse, se fac selectii, si se face comanda.
Detaliez mai jos ce fel de produse se vor lista in aplicatie
Produse si selectii - concepte
Produs
Poate avea Selectie#1
Poate avea Selectie#2
Produs combo
Selectie a doua sau mai multe produse
Poate avea Selectie#1
Poate avea Selectie#2
Selectia#2 poate fi listata de n ori
Detalii selectii
Selectie #1
Aceasta selectie defineste pretul produsului(ex: marimi produs)
Selectie #2
Aceasta selectie poate fi dependenta de #Selectie1(daca este prezenta). Poate avea un nr. minim și maxim de iteme, chiar si un nr. extra care se adauga la pretul final al produsului
Nu cred că vei găsi așa ceva pentru că e practic reinventarea roții.
În 2023 sunt atâtea solutii de e-commerce că nu merită efectiv.
De obicei în realitate se pornește fix invers:
întâi folosește o soluție gata făcută
Nu e suficient, faci customizare
Nu e suficient nici customizarea, faci soluție proprie.
E ca și cum ai cere azi de la cineva să îți facă un server de hosting propriu de la zero, când efectiv sunt pe toate gardurile soluțiile.
Dacă ai buget mare gen minim 50k să îți faci propriul e-commerce simplu de la zero cu tot ce include asta, vei găsi om. Altfel nu. Dar în final vei ajunge cu ceva ce arată 90% ca alte solutii, 0 support, 0 comunitate, 0 extensii compatibile existente, 0 teme vizuale, etc.
asta si pentru ca e greu sa iti dai seama in detaliu despre ce ai nevoie cand pornesti un shop.
cand pornesti deja practic o sa ai si cerinte mai clare, deci justificare pentru personalizare / constructie custom
Salut Emanuel
Total de acord cu tine… dar nu asta este problema mea.
Doresc sa dezvolt un API in Laravel care va fi consumat de catre o aplicatie de mobil. Eu am nevoie de design-ul bazei de date - partea de produse. Caut pe cineva cu experienta, care stie baze de date. Sunt cateva tabele… este vorba despre 30min de lucru.
Cum ai zis si tu… am cautat solutii ecommerce si am gasit https://aimeos.org/
Daca stiti ceva in directia asta… va rog sa imi spuneti
Chestia asta poti sa o faci si cu Wordpress si cu Magento 2 headless. Poti sa pui si un gateway in fata daca ai nevoie si beneficiezi de toate features.
sunt prea putine informatii sa imi dau seama daca e ce cauti,
dar eu am avut experiente reusite cu drupal commerce (proiecte care au adunat 10 ani de online si inca numara).
inainte de asta foloseam framework propriu, dar intretinerea si extinderea costau prea mult (in special in timp).
cu laravel nu am experienta relevanta, deci nu pot raspunde.
pai cat sa dureze pentru un om experimentat sa faca un copy-paste dintr-un proiect similar?
despre pret… e alta discutie.
Una e justificarea, alta e bugetul și rentabilitatea. Dacă deja produci suficienți bani cât să îți permiți customizare din prima, doamne ajută, nici o problemă, business is business.
Dar eu tot timpul dau de oameni care n-au 2 lei în buzunar dar le pute shopify, magento sau wordpress pe motiv că și prietenul lor au ceva de genul iar ei vor ceva mai ‘tare’ convinși că asta va fi edge-ul lor competitiv.
Toate soluțiile e-commerce au parte de api, nu e nici o problemă, îți creezi categoriile structura de care ai nevoie apoi te uiți cum arată API-urile și vezi de ce limite te lovești.
cu siguranta catalogul pizza se poate modela in mai toate frameworkurile ecommerce (inclusiv drupal),
insa baza de date o sa arate diferit in functie de frameworkul ales.
practic, exact pentru asta alegi frameworkul… pentru a nu mai lucra direct cu baza de date, ci cu un nivel mai sus - cu niste entitati mai apropiate de cele din realitate (pe langa comoditatea si siguranta unor lucruri deja dezvoltate / testate).
as mai adauga si faptul ca n-ar fi rau sa ai o discutie si cu developerul (cel care implementeaza efectiv solutia) despre solutii si structuri de genul.
da, proiectarea si implementare sunt lucruri diferite, insa nu cred ca niste solutii de pe un forum sunt mai potrivite decat directia recomandata de cel care implementeaza efectiv.
inteleg si conflictul de interese (developerul are interes sa ii fie usor / sa poata factura, pe cand ownerul are interes sa rezolve sustenabil si ieftin), dar tot nu cred ca locul forumului e mai mult decat o parere / informatie extra.
Asta caut eu, un Jedi, sa rezolve structura bazei de date. Ma mai uit si pe variantele ecommerce… poate, poate.
Eu nu sunt de acord cu tine. Nu cred ca baza de date trebuie sa stie ceva despre framework. Cred ca te referi la ORM-uri… cam toate pastreaza aceeasi linie.
Cum poate persoana X sa aprecieze cat dureaza punerea in aplicare a unui task (de catre persoana Y), atat timp cat persoana X nu are experienta necesara sa-l puna si singur in aplicare?
In fine, cred ca am eu o fixatie pe detaliu acesta. Puteti ignora offtopicul.
eu am spus-o cu un spirit de gluma.
sry daca nu era locul.
ontopic la durata… eu nu as putea factura 30 de min pt un task nou (in sensul de proiect nou) in nici o situatie.
dureaza mai mult de atat sa discut / inteleg taskul, sa testez, sa livrez efectiv, sa scriu macar o factura (daca nu e cazul de contract sau pv-predare-primire), etc.
apoi mai e diferenta dintre sistemele de tarifare pe care le practica developerii, diferenta de infrastructura, de experienta, etc.
pana la urma… rezultatul unui task o sa coste cam tot pe acolo daca are caracteristici similare (de urgenta, de forma si conexe ale livrabilului - ex documentatie, de angajament pentru asistenta ulterioara, etc).
doar ca pe factura poti vedea 1 ora x 500 euro sau 5 ore x 100 de euro (exemplu).
evident, exceptii se intampla, insa eu cam cu asta m-am intalnit.
si da, sunt de acord ca nu clientul evalueaz durata (el doar o agreeaza sau nu), dar sunt suficient de “batran” sa nu ma mai deranjeze detaliile astea.
eu sunt de acord ca nu trebuie sa fim de acord.
si directia e mai mult invers: frameworkul trebuie sa stie despre baza de date (si in functie de cum stie sa lucreze cu ea o sa fie si structura ei).
da, multe lucruri or sa fie similare (pentru ca problema e aceeasi in esenta), dar solutiile sunt multiple si forma finala o sa difere.
eu as considera un consultant care sa poata propune solutii (de alegere a tehnologiilor, de arhitectura, etc) in functie de nevoile tale.
modul in care ar formulat problema (un task specific pentru laravel) da impresia ca ai un bug / blocaj intr-un proiect deja in derulare si poate de aici neintelegerea.