Keskustelu: Ohjelmointikysymykset: Dynaaminen taulun luonti

Taulun luonti koodissa annetulla nimellä onnistuu. Olen kuitenkin etsinyt ohjetta, kuinka yhteen tietokantaan saisi kätevästi kullekin asiakkaalle oman taulun. Taulu siis tehdään käyttöliittymässä annetulle nimelle, esim '$customer', jossa arvo 'mottonen'. Prepare ja Concat ovat tulleet vastaan, mutta ei selkeätä ja nopsaan ymmärrettävää ohjetta. $mysqli->prepare -komennolla menee tauluun sujuvasti dynamista sisältöä, mutta taulun luonnissa jokin mättää.
Olisiko esimerkkiä saatavissa?

Edit: Onko parempi tehdä ensin taulu, jossa yksi sarake ja lisätä loput samassa koodissa erikseen? Sarakkeita on kaikkiaan 35 kpl.

Kuulostaa siltä, että tarvitset jonkinsortin koontitaulua.

Dynaaminen taulujen luonti on yleensä monimutkainen ja vaikeasti käsiteltävä ratkaisu eikä hyödytä mitenkään. Juuri kukaan ei vakavissaan käytä sitä, ja sen takia myöskään siitä ei löydy ohjeita.

Oikea ratkaisu on merkitä se $customer 'mottonen' (tai mielummin sen id kuten 123) niihin asioihin, jotka sille asiakkaalle kuuluvat asiakkaalle. Merkintää ei tarvitse laittaa kuin osaan tauluista: jos vaikka asiakkaalla on autoja ja autolla on renkaita, tiedetään, että myös asiakkaan auton renkaat kuuluvat asiakkaalle, vaikka renkaissa ei erikseen lue sitä.

Ellei sitten ole tarkoitus tehdä jokaiselle asiakkaalle suoranaisesti omaa kopiota koko järjestelmästä. Eli nyrkkisääntönä voisi sanoa, että asiakkaille kannattaa luoda omat kopiot joko kaikista tauluista tai ei mistään. Välimuodoille pitäisi olla aivan erityisen harkitut perustelut.

Metabolix kirjoitti:

Oikea ratkaisu on merkitä se $customer 'mottonen' (tai mielummin sen id kuten 123) niihin asioihin, jotka sille asiakkaalle kuuluvat asiakkaalle. Merkintää ei tarvitse laittaa kuin osaan tauluista: jos vaikka asiakkaalla on autoja ja autolla on renkaita, tiedetään, että myös asiakkaan auton renkaat kuuluvat asiakkaalle, vaikka renkaissa ei erikseen lue sitä.

Periaatteessahan väite on tulkittavissa oikein mutta tämä käyttäjä sitä tuskin ihan täysin ymmärtää, koska väite sisältää paljon "itsestäänselvyyksiä". Jos taulussa ei ole saraketta "asiakas_id", niin silloin ei voida suoraan tietää, kenelle asiakkaalle mikäkin rivi kuuluu. Eli kenelle ne autonrenkaat kuuluvat.

Ajatellaan että järjestelmässä on toiminto, missä voi hakea tietoa kannassa olevista autonrenkaista (esimerkiksi myydyt renkaat). Jos vain tyhmästi kirjoittaa "SELECT id, name, car_model FROM autonrenkaat WHERE brand LIKE '%nokian%'", niin se tosiaan sitten hakee kaikista taulussa olevista renkaista ja kaikkien asiakkaiden renkaista.

Jos järjestelmä on ns. keskitetty ratkaisu eli siellä on monta toisistaan eristettyä toimintaympäristöä, jotka eivät saisi vuotaa toistensa puolelle, niin tuollainen ajattelematon kysely on suoraan todella vaarallinen. Tässä tapauksessa on pakko liittää periaatteessa turha liitos sellaiseen tauluun, jolla renkaat ja asiakkaat voidaan luotettavasti liittää toisiinsa. Eli se voisi olla vaikka taulut autot:

SELECT a.id, a.name, a.brand FROM autonrenkaat a INNER JOIN autot b ON a.car_id = b.id WHERE b.customer_id = 'x' AND a.brand LIKE '%nokian%'

Eli nyt joutuu miettimään sitä, onko järkevämpää laittaa tauluun tieto asiakkaasta vai käyttää liitoskyselyitä aina tietoja hakiessa? Siihen ei ole yksikäsitteistä oikeaa vastausta vaan se riippuu tilanteesta.

Hyviä kommentteja,OK. Luovuttiin dynaamisesta taulujen tekemisestä. Sen sijaan on erikseen taulut tyyliin asiakas, yhteyshenkilö (sama voi olla usealla asiakkaalla) ja tapahtumatA, tapahtumatB. Ja yhteyshenkilön on tarkoitus nähdä avoimesti vain omansa. Vaati raportointihimmelin rakentamisen melkein uusiksi.