Forum » Programiranje » Dodajanje polj bazi v produkciji (MySQL)
Dodajanje polj bazi v produkciji (MySQL)
Gost ::
Kako bi naredil strukturo baze, kjer so v crm-ju kontakti z različnimi polji in različnih tipov (integer, varchar, text):
- Janez Novak (telefon, naslov1, naslov 2, telefon 1, telefon 2)
- Marija Horvat (gsm, email, barva las, leto rojstva)
Me lahko, prosim, kdo usmeri v pravo smer? Najlepša hvala.
- Baje, da spreminjanje strukture baze preko CRM-ja v tem primeru nikoli ni dobra rešitev in se je vsi raje izogibajo (update-i, vzdrževanje, backupi, bugi itd).
- XML polje v Mysql-u mislim, da ne obstaja
- rešitev s pomočjo večih tabel in relacij med njimi bi bila ok, vendar me skrbi, da bo potem kmalu vse skupaj zelo počasno
- Janez Novak (telefon, naslov1, naslov 2, telefon 1, telefon 2)
- Marija Horvat (gsm, email, barva las, leto rojstva)
Me lahko, prosim, kdo usmeri v pravo smer? Najlepša hvala.
- Baje, da spreminjanje strukture baze preko CRM-ja v tem primeru nikoli ni dobra rešitev in se je vsi raje izogibajo (update-i, vzdrževanje, backupi, bugi itd).
- XML polje v Mysql-u mislim, da ne obstaja
- rešitev s pomočjo večih tabel in relacij med njimi bi bila ok, vendar me skrbi, da bo potem kmalu vse skupaj zelo počasno
- spremenil: Gost ()
Mitja Bonča ::
Telefonske številke, naslov, barva las dej kot varchar,
leto rojstva, oziroma vse kar ima datum daj kot datetime ali date.
Telefosnke številke ti ne priporočam kot integer (števiko, ker integer mora bti število skupaj - brez presledkov, ša še če je 0 spredaj ti jo ne upošteva).
Kar se tiče več tabel najbolje je da daš ene stavati v eno tabelo, drugi v drugo in jih nato med sabo tudi pravilno povežeš z tujimi ključi.
Primer skupaj z eno sql poizvedbo: Dobi študente in njihove telefonske, ki so plačali račun v določenem obdobju:
Tabele:
Študenti(IDŠtudentaPK, Ime, Priimek, Naslov, Telefon, Rojstvo,...)
Računi (IDRačunaPK, IDŠtudentaFK, Znesek, Davek, DatumPlačila,...)
Parametra @datumDo in @datumDo sta datuma med materima poizvedba išče študente.
To je to.
lep pozdrav,
Mitja
leto rojstva, oziroma vse kar ima datum daj kot datetime ali date.
Telefosnke številke ti ne priporočam kot integer (števiko, ker integer mora bti število skupaj - brez presledkov, ša še če je 0 spredaj ti jo ne upošteva).
Kar se tiče več tabel najbolje je da daš ene stavati v eno tabelo, drugi v drugo in jih nato med sabo tudi pravilno povežeš z tujimi ključi.
Primer skupaj z eno sql poizvedbo: Dobi študente in njihove telefonske, ki so plačali račun v določenem obdobju:
Tabele:
Študenti(IDŠtudentaPK, Ime, Priimek, Naslov, Telefon, Rojstvo,...)
Računi (IDRačunaPK, IDŠtudentaFK, Znesek, Davek, DatumPlačila,...)
SELECT Ime, Priimek, Telefon FROM Študenti, WHERE Študenti.IDŠtudentaPK = Računi.IDŠtudentaFK AND ((DatumPlačila >= @datumOd) AND (DatumPlačila <= @datumDo))
Parametra @datumDo in @datumDo sta datuma med materima poizvedba išče študente.
To je to.
lep pozdrav,
Mitja
Zgodovina sprememb…
- spremenil: Mitja Bonča ()
Gost ::
Če prav razumem, predlagaš za vsak nov tip kontakta, ki ima poseben nabor lastnosti, novo tabelo? Torej bi naredil tabele:
- osebe_1 (id, ime, priimek, telefon, naslov_1, naslov_2, telefon_1, telefon_2)
- osebe_2 (id, ime, priimek, telefon, gsm, barva_las)
- ...
- osebe_1234 (id, ime, priimek, znamka_avtomobila)
Ni to malo nepregledno čez čas in podatki so decentralizirani? Očitno tukaj res brez prilagoditev zahtev ne bo šlo.
Na nekem forumu sem gledal, da so rešili podobno zadevo s pomočjo vnašanja XML podatkov. Vendar je bil zadaj SQL server 2005(8), ki ima poseben XML tip polja. Podoben problem je recimo tudi trgovinah, kjer imaš izdelke z različnimi atributi:
- majice (velikost, barva)
- motorji (pnevmatike, moč motorja)
Sedaj sem se spomnil še na možnost serializacije objektov in array-jev in bom morda uspel zaenkrat rešiti kar s tem. Če bodo pa performančni problemi, pa grem na uporabo večih tabel.
- osebe_1 (id, ime, priimek, telefon, naslov_1, naslov_2, telefon_1, telefon_2)
- osebe_2 (id, ime, priimek, telefon, gsm, barva_las)
- ...
- osebe_1234 (id, ime, priimek, znamka_avtomobila)
Ni to malo nepregledno čez čas in podatki so decentralizirani? Očitno tukaj res brez prilagoditev zahtev ne bo šlo.
Na nekem forumu sem gledal, da so rešili podobno zadevo s pomočjo vnašanja XML podatkov. Vendar je bil zadaj SQL server 2005(8), ki ima poseben XML tip polja. Podoben problem je recimo tudi trgovinah, kjer imaš izdelke z različnimi atributi:
- majice (velikost, barva)
- motorji (pnevmatike, moč motorja)
Sedaj sem se spomnil še na možnost serializacije objektov in array-jev in bom morda uspel zaenkrat rešiti kar s tem. Če bodo pa performančni problemi, pa grem na uporabo večih tabel.
Mitja Bonča ::
Ne, osebe so en objekt, torej za njih samo ena tabela. Bodo pač vse osebe imele vse lastnosti, saj te itak nikoli ne škodijo. Ene bobd pač imele vrednost "null".
Ne moreš imeti za eno in isto osebo 2 ali več Id-jev. To ne gre. Zato pa so ID-ji - edinstveni ključi - eden in edini!!!
Jaz imam v mislih različne tabele za:
1. Osebe (IdOsebe, ImePriimek, telefon, gsm, naslov1, naslov2, barvaLas, avtomobil, državaRojstva, državljanstvo, Živi,...)
--- če imaš vse te tabele tukaj, moraš v tabelo Osebe dodati tuje ključe drugih tabel---
1.1 Osebe (IDOsebe, IDAvtomobilaFK, IDDržaveFK, IDKrajaFK)
2. Avtomobili (IDAvtomobila, Znamka, Model, DržavaPorekla, letoIzdelave, barva, ...)
3. Države(IDDRžave, ImeDržave)
4. Kraji(IDKraja, IDDržaveFK, ImeKraja)
u got the point?
Ne moreš imeti za eno in isto osebo 2 ali več Id-jev. To ne gre. Zato pa so ID-ji - edinstveni ključi - eden in edini!!!
Jaz imam v mislih različne tabele za:
1. Osebe (IdOsebe, ImePriimek, telefon, gsm, naslov1, naslov2, barvaLas, avtomobil, državaRojstva, državljanstvo, Živi,...)
--- če imaš vse te tabele tukaj, moraš v tabelo Osebe dodati tuje ključe drugih tabel---
1.1 Osebe (IDOsebe, IDAvtomobilaFK, IDDržaveFK, IDKrajaFK)
2. Avtomobili (IDAvtomobila, Znamka, Model, DržavaPorekla, letoIzdelave, barva, ...)
3. Države(IDDRžave, ImeDržave)
4. Kraji(IDKraja, IDDržaveFK, ImeKraja)
u got the point?
Zgodovina sprememb…
- spremenil: Mitja Bonča ()
Gost ::
Now I got the point. Zanimiva rešitev za res kompleksnejše probleme. Čeprav me malo moti in skrbi, ker se bo shema baze potem spreminjala. Bom preštudiral in pretehtal pluse in minuse. Najlepša hvala za pomoč.
Mitja Bonča ::
To niso zanimive rešitve - tako se dela. In ti toplo priporočam, slpoh če si začetnik, da se tega držiš. Boš imel veliko manj problemov.
Uživaj :)
Uživaj :)
gokky ::
Če imaš veliko polj, ki so med posameznimi tipi smpremenljivi, lahko imaš recimo (in zelo na grobo rečeno) lahko tudi variabilne stolpce:
Osebe (idoseba, skupna polja)
Stolpci (idstolpec, tip, šifra, kratek opis,...)
Osebe_Stolpci (idosebe, idstolpec, vrednost )
Vse tri tabele so ti v bistvu za eno tabelo oseb, ki imajo različne podatke.
Osebe (idoseba, skupna polja)
Stolpci (idstolpec, tip, šifra, kratek opis,...)
Osebe_Stolpci (idosebe, idstolpec, vrednost )
Vse tri tabele so ti v bistvu za eno tabelo oseb, ki imajo različne podatke.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | SQL težava z vmesnimi tabelamiOddelek: Programiranje | 1832 (1437) | zavajon |
| » | PostgreSQL pomočOddelek: Programiranje | 2503 (1996) | Mato989 |
| » | Matura 2 predmet E-redovalnicaOddelek: Programiranje | 1435 (1069) | FiR3F0X |
| » | SQL poizvedbaOddelek: Programiranje | 2163 (1673) | borchi |
| » | SQL vprašanjeOddelek: Izdelava spletišč | 2666 (2229) | jerneju |