Hirdetés
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- eBay-es kütyük kis pénzért
- LordAthis: RETRÓnia - RETRÓ Mánia - Úton van hozzám egy csodás történelmi darab!
- sh4d0w: Kalózkodás. Kalózkodás?
- gban: Ingyen kellene, de tegnapra
- Lalikiraly: Kinek milyen setupja van?
- sh4d0w: Árnyékos sarok
- Pajac: A csodálatos mandarin
-
LOGOUT
Új hozzászólás Aktív témák
-
#9299
fordfairlane
veterán
Bambula5
#9297
fordfairlane
veterán
-
-
válasz
Bambula5
#9269
üzenetére
Csinálj egy külön táblát a stringeknek, kb így:
LocalizedStrings
StringID - a string azonosítója
LanguageID - a nyelv azonosítója
String - maga a string(A StringID nyilván nem lesz unique, mert ha három nyelvet támogatsz, akkor háromszor fog szerepelni.)
Aztán ott, ahol most varchar-ok vannak, azokat cseréld le egy StringID mezőre.
(#9270) Jim Tonic: a productname önmagában kevés lesz, mert pl. a tulajdonságok neveit, ha stringek, akkor az értékeit meg a kategóriákat is lokalizálni kellene, meg ha beesnek egyéb stringek is később, akkor azokat is
-
-
válasz
Bambula5
#9251
üzenetére
Oké, ebben az esetben nincs is nagyon más választásod.
Mondjuk így elsőre nem igazán tudom, ez miért jó neked. Nem lenne jobb úgy kialakítani a kategóriákat, hogy erre ne legyen szükséged? Addig visszamenni egy fán, míg elérsz egy közös pontig, és onnan lefelé az első szinttel kezdeni.
A többit nagyjából írta Bambano közben. Ha annak végére értek, folyt köv., ne futtassunk 3 szálon, mert nincs értelme.Bambano: "van, a régebbi netbeansek, pláne visualwebpack-kel súlyosbítva, meg sem nyikkantak elsődleges kulcs nélkül." Ok, félreértettelek, az elsődleges kulcs oké, azt hittem, arra gondolsz, az ID mező kötelező.
-
válasz
Bambula5
#9245
üzenetére
ez így konkrétan pont nem jó, ha a values of properties kapcsolódik a properties of productshoz, akkor ha egy értéket törölsz a values of properties táblából, szétszakad a tranzitív kapcsolat a termék és a terméktulajdonság között.
én úgy csinálnám, hogy van a termék, mint szülő a gráfban, annak a gyereke a terméktulajdonság, annak a gyereke a terméktulajdonság érték.
persze ezzel már sérül a konzisztencia szerintem, mert mi van akkor, ha ugyanolyan termékből van több, ami csak egy tulajdonságában különbözik? pl. szeletelt karaj, tálcás csomagolásban, 20 deka és 50 deka.
szerk: másik probléma: ha nincs közvetlen kapcsolat a termék és a terméktulajdonság táblák között, akkor nem fogod tudni összeállítani azt az űrlapot, amivel felviszed egy adott termék tulajdonságtípusainak értékeit. tehát honnan fogja tudni a programod, hogyha cipőt visznek be, ott kell a lábméret, ha meg tejet, ott a liter?
-
-
inf3rno
nagyúr
válasz
Bambula5
#9245
üzenetére
A NuoDB newSQL, nem noSQL. Van egy csomó új fajta SQL adatbázis , amik sokkal gyorsabbak a régebbieknél, és lazán eljátszadoznak több millió sorral. [link] Ruby-val a látottak alapján talán jobban jársz, ha maradsz a régieknél, esetleg kipróbálsz olyan adatbázist, aminek van REST API-ja (általában szokott lenni), így kikerülheted azt a problémát, hogy nincs csatoló. Gondolom HTTP-t csak tud a ruby valami cURL-el vagy hasonlóval.
-
inf3rno
nagyúr
válasz
Bambula5
#9221
üzenetére
Elvileg a postgresql, amit írtál elég lehet. Ha túl lassú lenne, akkor váltanod kell noSQL-re vagy newSQL-re. Az utóbbiból nézegettem ruby-s gem-eket, NuoDB-hez volt valami tűrhető, de már azt is 2 éve nem fejlesztik, lehet, hogy fel se tudnád telepíteni, build failing-et ír a travis. [link] Nem egy jó nyelv ilyen szempontból a ruby, meg amúgy sem, legalábbis sokan nem szeretik. Én inkább távol tartom magam tőle.
-
-
válasz
Bambula5
#9235
üzenetére
Ez így rossz struktúra.
A tulajdonság táblának így fuss neki:
1. tulajdonság_tipus: integer, char, stb, ami a legjobb neked
2. tulajdonsag: char
A második mezőben azt tárolsz, amit akarsz. Tehát a termékfajta_id és a tulajdonsag_tipus_id az 1. mezőbe megy, a hozzárendelt adat pedig a másodikba.Az áru értéket teljesen máshol kell tárolni. Annak érvényességi ideje, pénzneme, vevő/szállító kapcsolata, stb. lehet.
Nem akarok gonosz lenni, de ha ez akkora projekt, akkor kérj segítséget az adatbázis megtervezése előtt, mert elsőre kicsit úgy tűnik, hogy ködben tapogatózol. Tényleg nem okoskodásból mondom, de az brutális bukta, ha utólag derül ki, hogy rossz az adatstruktúrád. Inkább mesélj itt többet róla, és beszéljük át többször. Én ERP-t fejlesztek évek óta, nagy titkokat nem fogsz nekem elárulni, szóval ettől nem kell félned. De ahogy érzed. -
válasz
Bambula5
#9235
üzenetére
akkor rakjál bele mindegyikből.
tehát legyen benne: ertek_int, ertek_real, ertek_text, ertek_bool mező és használd azt, amelyik kell. tudtommal a postgres az üres mezőknek nem foglal túl sok helyet, nem nagy pazarlás.illetve még mindig forszíroznám az elvet, hogy bizonyos esetekben olcsóbb az emberi/programozói/fejlesztői erővel spórolni, mint a hardverrel. néha jobb megoldás pazarolni a hardvert.
-
válasz
Bambula5
#9221
üzenetére
A táblákba szétszedés a sebességet nem fogja feltétlenül javítani
Azt már tudod, hogy mi alapján kell keresned?
Mert ha a tulajdonságok alapján (amik elég dinamikusnak tűnnek), akkor lehet, hogy jobban járnál egy nosql adatbázissal.(#9223) emvy: tisztán a gyakorlatitapasztalatmentes okoskodás szintjén azért segíthet, ha nem minden rekordon külön lemezblokkból kell összevadászni, hanem egy olvasással megvan egy rakat sor (feltéve, hogy a sorok elég rövidek)
-
válasz
Bambula5
#9221
üzenetére
A problémám az lenne, hogy tekintettel a rengeteg termékre és azok különböző tulajdonságaira nem lenne szerencsés egy táblában tárolnom őket. Miként lehetne megoldani, hogy egy-egy alkategória létrehozásánál létrejöjjön egy hozzá tartozó termék tábla? Gondolom ez a keresést is felgyorsítaná...
Triggerekkel lenne a legelegánsabb megoldani, de szerintem nem ez a jó irány. Óriási adatbázisokban sem szokás ugyanolyan típusú adatot más táblában tárolni. Az tudod milyen mélységig vannak alkategóriák? Szerintem egyéb paramétereket kell használni, és okosan indexelni.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- iPhone topik
- Milyen videókártyát?
- Apple iPhone 16 - ígéretek földje
- Yettel topik
- Kormányok / autós szimulátorok topikja
- Apple iPhone 15 Pro Max - Attack on Titan
- Fejhallgató erősítő és DAC topik
- Elektromos autók - motorok
- Miskolc és környéke adok-veszek-beszélgetek
- Wise (ex-TransferWise)
- További aktív témák...
- Sapphire Pulse 6800XT 16Gb Kitűnő! Ingyen posta!
- Cisco Telepresence MX300 G2 - 55" Interaktiv Monitor - Konferencia rendszer
- 70" Interkativ Érintőképernyős Monitor / All In one PC - InFocus INF7021A Multi Touch
- Microsoft Surface Hub (v1) 1597 - 55" All in One PC - Érintőképernyős monitor
- Dell PowerSwitch N2048 48 Port Gigabit Ethernet 2 Port 10Gb SFP+ Switch
- Jabra Speak2 75 MS Teams USB-bluetooth hangszóró
- Eredeti Lenovo 230W töltők - 4X20Z83995
- REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 Dock
- 2db x Green Cell UPS 2000VA 1200W teljesítményálló tartalék tápegység 2000VA 1200W
- Dell D6000 univerzális dokkoló USB-C/ USB-A, DisplayLink & Dell WD15 (K17A) USB-C + 130-180W töltő
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest