Hirdetés
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- laca223: Miért győz a kollektív meggyőződés akkor is, ha saját magát teszi tönkre?
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Gurulunk, WAZE?!
- Magga: PLEX: multimédia az egész lakásban
- Toomy: FOXPOST régen jó volt, de ma már jobban jársz ha elfelejted.
- bambano: Bambanő háza tája
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT

Új hozzászólás Aktív témák
-
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.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi


