- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen notebookot vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- iPad topik
- 3D nyomtatás
- Akciókamerák
- Soundbar, soundplate, hangprojektor
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
-
PROHARDVER!
Ú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ő.
-
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.
-
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
Hirdetés
● olvasd el a téma összefoglalót!
- Kertészet, mezőgazdaság topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: AMD Ryzen 7 7700X vs AMD Ryzen 9 9900X AIDA64, és PCMark 10 Benchmarkokban mérve
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Óvodások homokozója
- Hálózati / IP kamera
- Futás, futópályák
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- A lemondást javasolja az Intel vezetőjének Donald Trump
- Telekom mobilszolgáltatások
- További aktív témák...
- ÚJ Lenovo LOQ 15IRX9 - QHD 165Hz - i7-13650HX - 16GB - 1TB - RTX 4060 - Win11 - 3 év garancia - HUN
- Bomba ár! Dell Latitude 5400 - i7-8GEN I 8GB I 256SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- BESZÁMÍTÁS! Gigabyte B450M R5 5600 16GB DDR4 512GB SSD GTX 1080Ti 11GB ZALMAN I3 NEO Chieftec 650W
- Csere-Beszámítás! Ajándék ROG Táska! Asus Rog Ally Z1 Extreme RC71L - 512GB SSD + 16GB LPDDR5
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
Állásajánlatok
Cég: FOTC
Város: Budapest