| Autor | Zpráva | ||
|---|---|---|---|
| ronnie Profil |
#1 · Zasláno: 7. 7. 2005, 11:56:09
Dobrý den,
potřeboval bych od vás pomoci. Právě dělám internetový obchod a potřebuji něco vyřešit. Internetový obchod se skládá z několika sekcí (např. mobily, pc ap.), u každé sekce je možné zadat zvláštní parametry (např. u mobilu výdrž baterie, u pc paměť ap.). Jde o to, že každá sekce má jiný počet parametrů. Administrátor má mít možnost ke každé sekci přidávat nové parametry, nebo starší mazat (i když je eshop už zaběhlý). Jak tedy vytvořit a zapisovat zvláštní parametry? Napadá mě jediný způsob. Když si administrator založí novou sekci, nabídnu mu rovněž zadat počet zvláštních parametrů. Následně ho přenesu na stránku, kde bude formulář s počtem inputu, které zadal dříve (počet parametrů). Pak by zadal nazvy parametrů. Když by odeslal formulář, automaticky by se vytvořila tabulka zvláštních parametrů pro každou sekci a u každého výrobku by script automaticky generoval zvláštní parametry. Problém však nastává v úpravě některých parametrů, pokud se rozhodne např. nějaký smazat, bude třeba upravit tabulku pomocí různých příkazů alter. To mě však připadá dost nepraktické, pokud bude třeba 20 sekcí vytvářet dalších 20 tabulek..:/ Nevíte někdo jakým způsobem se tyto záležitosti řeší? Mnohokrát děkuji za každou odpověď. |
||
| Charlie Profil |
#2 · Zasláno: 7. 7. 2005, 13:26:03
Já bych pro každou sekci udělal jednu tabulku a do ní bych uložil neutrální parametry. Do každého řádku bych dal asi tohle:
1) ID výrobku 2) Speciální kód výrobku 3) Název výrobku 4) 5 krát neutrální pole varchar(255) pro kratší popisky, názvy 5) 5 krát pole int třeba pro hodnotu ceny 6) 2 krát pole blob pro kratší a delší úplný popis Pak si uděláš konfigurační tabulku, do které dáš, co který klíč znamená. |
||
| printf-jinde Profil * |
#3 · Zasláno: 7. 7. 2005, 15:14:29
Neutrální pole jsou zajímavý nápad, ale obávám se že by se velmi špatně udržoval význam jednotlivých polí (třeba by za rok nebylo jasné, které pole je cena a které hmotnost). Ještě horší by bylo, kdyby se objevila potřeba více parametrů. Navíc by se při každém výpisu muselo řešit co je který parametr a jak ho interpretovat.
Možná by to bylo pomalé, ale co zkusit něco jako XML? V tabulce by bylo pole "parametry" typu text a v něm by mohly být libovolné označkované parametry. Např: <HMOTNOST>205</HMOTNOST><VYDRZ>20</VYDRZ><MODEL>Worty</MODEL>... pak by byla další tabulka, kde by byly všechny typy parametrů (hmotnost,vydrz,model...) a jejich jednotky (g,h,,...). Tím by mohlo být "libovolně" libovolných parametrů, akorát by to musel nějaký algoritmus dostatečně rychle zpracovat. Ještě lepší by bylo mít další pole, třeba "vypis" kde by byl přímo html kód s parametry, který se bude vypisovat zákazníkovi a nebude zbytečně zatěžovat server jeho sestavováním. Když bude správce parametry měnit, tento html kód se automaticky obnoví. No a pro hledání zboží podle parametrů to už holt bude muset hledat v těch značkách, ale předpokládám že se to zase tak často dít nebude. Snad jsem se vyjádřil srozumitelně :-) |
||
| ronnie Profil |
#4 · Zasláno: 7. 7. 2005, 16:07:23
Nedavno jsem si koupil knihu xml v kostce...takže to abych začal studovat pořádně další jazyk:) Každopádně díky oběma:)
|
||
| Martin Kuželka Profil |
#5 · Zasláno: 7. 7. 2005, 16:21:31
printf-jinde: imho je tvoje řešení úplně nesmyslné. Právě na takové věci jako eshopy jsou db přímo ideální, tak nevím, proč vymýšlet něco jiného.
|
||
| printf-jinde Profil * |
#6 · Zasláno: 7. 7. 2005, 17:24:24
Martin Kuželka
Asi jsem to nenapsal dost přesně, ale to moje XML je jako nadstavba do databáze, protože XML má oproti databázi tu výhodu, že nemusí mít tak striktně tabulkově danou strukturu. Moje řešení je tedy databáze (tam by byly hlavní parametry, jako cena, název...) a jedno z políček by obsahovalo všechny volitelné parametry a to označené jako v XML aby se daly rozpoznat. Přijde mi to smysluplnější než definovat pro každé zboží několik prázdných buněk které se třeba ani nevyužijí. A ta buňka s tou HTML částí má zrychlit zobrazování zboží a tím usnadnit provoz celého eshopu-pravda na úkor místa. Takže souhrnem: navrhuju POUŽÍT databázi, s tím že jedna z buněk té databáze bude vždy použita pro uložení volitelných parametrů, jejichž počet a délka nebudou předem dané. Tyto parametry budou rozlišeny XML značkami. |
||
| Kaifman Profil |
#7 · Zasláno: 7. 7. 2005, 23:28:37 · Upravil/a: Kaifman
a co takhle to udelat tim zpusobem ke kteremu jsou relacni databaze urceny :-)
tabulka parametry (idparametr, jmeno_parametru) tabulka hodnoty_parametru (idparametr, idzbozi, hodnota) tabulka zbozi (idzbozi, jmeno_zbozi, atd) a mezi nima tabulka ktera vytvari relaci M:N idparametr, idzbozi sou zaroven primarni klice i cizy klice do tech dvou tabulek zbozi a parametry a select kterej ti vypise prislusny parametry i s hodnotama od nejakyho vyrobku bude vypadat takhle select jmeno_parametru, hodnota from parametry natural join hodnoty_parametru natural join zbozi where jmeno_zbozi='nočník'; |
||
| Kaifman Profil |
#8 · Zasláno: 7. 7. 2005, 23:36:24
jinak se muzes kouknout treba na oscommerci kde mas neco podobneho na stejnem pricnipu jako sem popsal , kazdej vyrobek muze mit svoje vlastni paramatry a kazdej muze mit kolik chce nezavisle na druhem
|
||
| printf-jinde Profil * |
#9 · Zasláno: 8. 7. 2005, 08:52:18
tak je to správné, ale všechny parametry musí být jednoho typu, ne? No v eshopu to asi nevadi.
|
||
| Anonymní Profil * |
#10 · Zasláno: 8. 7. 2005, 09:18:27
asi nejpouzitelnejsi by bylo aby byly hodnoty najekeho retzcoveho typu , int by ti byl celkem na nic kdyby si chtel tam nejakej retezec a php je netypovy takze tam je to suma fuk
|
||
| kaifman Profil |
#11 · Zasláno: 8. 7. 2005, 09:23:31
to sem psal já
jinak doporucuju analýzu a návrh neodbývat, práci kterou teď ušetříš když neuděláš pořádně tyto dvě věcí , můžeš mnohokát ztratit přepisováním projektu protože pak zjistíš že to nebude splňovat potřebné požadavky a funkčnost. |
||
| ronnie Profil |
#12 · Zasláno: 8. 7. 2005, 09:31:18
Ano, analýu samozřejmě nepodceňuji, ten eshop měl být původně jedodušší, teprv až v průběhu výstavby se začaly měnit poždavaky klienta. Díky mc za pomoc
|
||
|
Časová prodleva: 19 let
|
|||
Toto téma je uzamčeno. Odpověď nelze zaslat.
0