- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sh4d0w: Palpatine - A Terv
- weiss: Pant* rant
- N€T0X|N: SSD cserék
- bambano: Bambanő háza tája
- sh4d0w: Árnyékos sarok
- eBay-es kütyük kis pénzért
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
-
LOGOUT
Új hozzászólás Aktív témák
-
#9299
fordfairlane
veterán
Bambula5
#9297
fordfairlane
veterán
-
dabadab
titá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ő.
-
bambano
titán
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. -
bambano
titán
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.
-
dabadab
titán
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!
- Futás, futópályák
- Elképesztően drága az új Ryzen Threadripper PRO generáció
- Xiaomi Smart Band 10 - a hetedik napon megpihen
- EAFC 25
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Hegesztés topic
- Autós topik
- Iszonyatos mennyiségű hulladékkal járhat a Windows 10 terméktámogatásának vége
- Nyaralás topik
- További aktív témák...
- Gigabyte B450M S2H + Ryzen 5 1400 kisebb-nagyobb hibával
- Nokia 105 4G (2023) charcoal, Nokia 110 4G (2023) midnight blue
- ASRock B550 PG Velocita + Ryzen 5 3600 + 32GB (4x8GB) DDR4 3600Mhz CL18
- Philips 58PUS8505 Smart LED Televízió,146 cm, 4K Ultra HD ,Android, Ambilight, HDR10+ KIJELZŐHIBÁSAN
- Canon EOS 250D kiegészítőkkel, táskával (CSAK 200 expoval !!! )
- Bomba ár! Lenovo ThinkPad T15 G1 - i5-10GEN I 16GB I 256GB SSD I 15,6" FHD Touch I Cam I W11 I Gari!
- Telefon felvásárlás!! Apple Watch Series 6/Apple Watch Series 7/Apple Watch Series 8
- Fotó állvány eladó
- ÁRGARANCIA! Épített KomPhone Ryzen 7 5700X 32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W10 I Cam I Gari!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest