Erstat del af udtræk med andet fra samme mysql

<ole>

Ved forespørgslen trækker du vel bare navnet ud af tabellen og bruger det i stedet for ID'et. Når dit udtræk ser ud, som det gør, kan jeg ikke rigtig forstå, hvad problemet skulle være. Du har jo allerede navnet  =)

/mvh
</bole>

Hej olebole,

Jeg har været upræcis.
Det er selve id'erne i fx: Bor tæt på: 2, 3 som skal erstattes så det bliver: Bor tæt på: Peder Clausen, Niels Nielsen

Så kalder du tabellen med de ID'er og finder deres 'ejermænd'

hvis din "Tætpå (Id) / Langtfra (Id)", indeholder en komma seperret string skal den bare exploderes http://dk.php.net/explode og slå bruger navnet op som ole skriver

jeg vil anbefale dig at
lave by om til feks bynavn, da by er et reseveret ord i sql (du er vel støt på order by :) )
undgår æøå i dine tabel og kollonne navne

lav en seperat tabel til dine bynavne (postnummer tabel), så du skrive postnummeret istedet for bynavnet, du undgår stavefejl, og gør søgning mere præcis,

søgning http://www.postdanmark.dk/da/Sider/Search.aspx?k=postnummerfil&s=dk_da
fil http://www.postdanmark.dk/da/documents/lister/postnummerfil_excel.xls

JEg kan se hvordan jeg gør det med en seperat query for HVERT id, men kan det ikke gøres simplere? Gerne eksempel

Det er for den sags skyld rigtig nok, at man skal passe på reserverede ord (f.eks. by) i MySQL, men med god kodeskik betyder det ikke noget. Bruge altid backticks på alle navne:


- så udløses ingen fejl, selvom man skulle komme til at bruge et reserveret ord.

Du kan sagtens hente flere på én gang:

- men hvis du har 'tæt på' og 'langt fra' liggende kommasepareret, kunne det tyde på, du burde flytte dem til en tabel for sig selv og relationere de to tabeller(?)

hrole, jeg hører også til dem der bedre kan klare forklaringer skåret ud i pap end alt for teoretiske betragtninger.  Lad os prøve sådan her:

Det opstillede problem har to stadier.  Først skal du have dataerne trukket ud af database tabellen, og derefter skal du have de udtrukne dataer presenteret på siden.  Jeg skal her holde mig til det første stadie, at udtrække dataerne fra databasen.  Det med at presentere det på siden kan vi så vende tilbage til.

Hvis der for hver person kun var en person tæt på og en person langt fra, så var det nemmere.  For test lavede jeg denne tabel:

CREATE TABLE hrole(id INT, Fornavn VARCHAR(10), Efternavn VARCHAR(10), Tætpå INT, Langtfra INT);
INSERT INTO hrole VALUES(1, 'Mads', 'Larsen', 2, 3);
INSERT INTO hrole VALUES(2, 'Peter', 'Klausen', 3, 1);
INSERT INTO hrole VALUES(3, 'Niels', 'Nielsen', 1, 2);

Med denne forespørgsel:
SELECT h.Fornavn, h.Efternavn, (SELECT CONCAT_WS(' ', Fornavn, Efternavn) FROM hrole WHERE id = h1.Tætpå) AS Tætpå, (SELECT CONCAT_WS(' ', Fornavn, Efternavn) FROM hrole WHERE id = h.Langtfra) AS Langtfra  FROM hrole h

fik jeg dette resultat:

Fornavn Efternavn Tætpå Langtfra
Mads    Larsen    Peter Klausen    Niels Nielsen
Peter    Klausen    Niels Nielsen    Mads Larsen
Niels    Nielsen    Mads Larsen    Peter Klausen

Men du lægger en liste af tætpå værdier ind i et felt i database tabellen (og ligeledes med langtfra værdier.  Relationelle databaser er indrettede på, at sådanne lister ligger i særskilte tabeller.  Jeg lavede, igen for test, denne hroleTæt tabel:

CREATE TABLE hroleTæt(person INT, nabo INT);

INSERT INTO hroleTæt values(1, 2);
INSERT INTO hroleTæt values(1, 3);
INSERT INTO hroleTæt values(1, 4);
INSERT INTO hroleTæt values(2, 3);
INSERT INTO hroleTæt values(3, 4);
INSERT INTO hroleTæt values(3, 5);
INSERT INTO hroleTæt values(4, 1);

Altså person nummer 1 har personerne 2, 3, og 4 som tæt på o.s.v.  Dertil lavede jeg denne tabel hvor tætpå og langtfra er renset ud:

CREATE TABLE hrole1(id INT, Fornavn VARCHAR(10), Efternavn VARCHAR(10));
INSERT INTO hrole1 VALUES(1, 'Mads', 'Larsen');
INSERT INTO hrole1 VALUES(2, 'Peter', 'Klausen');
INSERT INTO hrole1 VALUES(3, 'Jens', 'Jensen');
INSERT INTO hrole1 VALUES(4, 'Ole', 'Olsen');
INSERT INTO hrole1 VALUES(5, 'Hans', 'Hansen');

Denne forespørgsel:

SELECT h.Fornavn, h.Efternavn, (SELECT CONCAT_WS(' ', Fornavn, Efternavn ) FROM hrole1 h1 WHERE h1.id = t.nabo AND t.person = h.id) AS tæt FROM hrole1 h LEFT JOIN hroleTæt t ON h.id = t.person

gav dette resultat:

Fornavn Efternavn tæt
Mads    Larsen    Peter Klausen
Mads    Larsen    Jens Jensen
Mads    Larsen    Ole Olsen
Peter    Klausen  Jens Jensen
Jens    Jensen    Ole Olsen
Jens    Jensen    Hans Hansen
Ole    Olsen    Mads Larsen
Hans    Hansen    NULL

Jeg har her, som en forenkling, udeladt langtfra'erne, men det laves efter samme princip.

Jeg håber det giver dig noget at arbejde videre med.

"alt for teoretiske betragtninger" ... hvaaaaaad ...?!??!!! Hvor?  :D

Tak for jeres kommentarer, jeg overvejer at ændre min db struktut, men fik en tanke.

Er det muligt at trække Id, Fornavn og Efternavn ind i et array inden jeg kører min while løkke og så i selve løkken erstatte tæt-på id med navnet?

hrole, for at få fat på fornavn og efternavn skal du have en id, et tal.  '3,4,5' er ikke et tal.  Det er ikke engang tre tal men en tekststreng.  Så du skal have numrene 'pakket ud', og derefter søge efter navnene der svarer til id=3, id=4, og id=5.

Jeg kender ikke nogen mysql funktion til at splitte en streng.  For selv at prøve at lære mere googlede jeg rundt, men jeg endte op tomhændet.  Man kan naturligvis skrive stored procedures til stort set alt, og jeg fandt dette eksempel, men jeg tror ikke det er sådan noget du er ude efter:

http://www.marcogoncalves.com/2011/03/mysql-split-column-string-into-rows/

Altså, du kan ikke i mysql splitte '3,4,5' til tre tal som du så kan bruge som id'er for at finde navnene. 

Men i php kan du, som ronols siger i #4, splitte strengen og få dine tal, men så skal du for hvert tal tilbage i mysql for at få navnene.

Hvis dit system er relativt lille (ikke tusindvis af navne og stort set kun dig selv som bruger) kan jeg godt se, at det kan være lettere bare at bruge en enkelt tabel og så putte tætpå og langtfra ind i et enkelt felt, men så kunne du bruge navnene direkte i stedet for numrene, såsom:

id fornavn efternavn tætpå ...
3    Niels    Nielsen      Mads Larsen, Ole Olsen, Hans Day
5    Peter    Klausen      Ib Nybo, Kaj Smit

I så fald kunne du med en enkelt søgning få alle de data du skal bruge for i php at stille det op som du ønskede.

Jeg tillader mig at oprette dette som et svar, idet jeg mener at have bidraget til at besvare spørgsmålet.  Du vil velsagtens også invitere svar fra andre når du skal til at lukke.

@Christian: Hvis det er så let med én tabel, kan det jo kun undre, at du som handlingens mand - teoriens og omtankens sande betvinger - må bruge så mange ord på det  *D

Jeg har netop modtaget en PB fra Christian_Belgien med information om, at han har klaget over min kommentar i #12. Jeg mener i modsætning til Christian ikke den slags skal gemmes væk i perosnlige beskeder, men tages der, hvor den hører hjemme - altså her i tråden.

Min kommentar (som var ment som en homoristisk bemærkning ... bemærk grinende smiley) var foranlediget af Christians forsøg på patronisering af ronols' og mine kommentarer i #8:

"hrole, jeg hører også til dem der bedre kan klare forklaringer skåret ud i pap end alt for teoretiske betragtninger.  Lad os prøve sådan her:".

Det er svært at se, hvad tanker og kommentarer omkring god kodeskik kan have med teoretiseren at gøre. Det var tværtimod yderst relevante informationer - og det er jo lidt pudsigt at tale om "alt for teoretiske betragtninger", når man selv efterfølgende bruger små 5.000 tegn på at forklare sig  =)

ref #11 Hvis dit system er relativt lille (ikke tusindvis af navne og stort set kun dig selv som bruger) kan jeg godt se, at det kan være lettere bare at bruge en enkelt tabel og så putte tætpå og langtfra ind i et enkelt felt, men så kunne du bruge navnene direkte i stedet for numrene, såsom:
det ville som jeg ser det være noget af det dummeste at gøre (bare for at spare et opslag), hvad hvis en person skifter navn ??, bliver det rettet alle steder ?? (tror jeg ikke), du bør bruge brugerens id og så lave det ekstra opslag.
ide'en med at ligge den ud i en seperat tabel er værd at overveje (og i normalicering af databaser's princip), jeg tror dog jeg ville slå de 2 tabeller fjern/nær sammen og sette et flag om det er nær eller fjern
og selvføgelig bruge en postnummer/by tabel hvis man har den i forvejen.

ide til db structur:

@ronols: Helt enig! Man kunne måske endda oprette en foreign key, da det nu er InnoDB, du har valgt som eksempel. Det vil forbedre performance ved en joined SELECT - ligesom man kan sætte en cascade, så data i 'located' tabellen automatisk slettes, når det element i 'users', de knytter sig til, slettes.

Offtopic / admin: Har set på begge anmeldelser. Ser glimtet i øjet. Vælger derfor at lade det ligge.

Tak, og jeg vil naturligvis gerne lige understrege, at min kommentar (#13) om "en homoristisk bemærkning" skal ses som en 'forskrivelse'. Muligvis opstået fordi, der kørte (eller lige havde kørt) en TV-udsendelse i baggrunden - en portrætudsendelse om Manu Sareen og nye regler omkring ægteskabsløfte og køn. Der skulle selvfølgelig stå "humoristisk"  *o)

Det var bare en SM-fejl ... ehhh, altså ... ehhhhh ... ja, altså en slåfejl!  *D

@Lars: Hvis du læser med, skal du lige vide, at jeg nu tre gange i dag har måtte logge ud og ind igen for at se kommentarer, jeg har fået mail om. #17 i denne tråd kunne jeg ikke engang se, efter jeg havde skrevet den - og en anden bruger har lige nævnt samme problem i en anden tråd.

Der er (blandt en del andre) en caching fejl på sitet, som det ville være rigtig rart at få rettet. Det vil jeg meget hellere have rettet, end jeg vil vinde en iPad (Som jeg lige har fået 'spammail' om)  *o)

Lars, det må jeg så tage til efterretning.  Tak fordi du kikkede på det.

#13: Jeg har villet supplementere, sikkert ikke patronisere.  Hvis jeg har udtrykt mig så det kunne forstås anderledes, så må i undskylde.  #7 siger, correkt, HVAD der bør gøres, nemlig at flytte 'tætpå'erne til en tabel for sig selv og relationere tabellerne.  Fordi spørgsmålsstilleren flere gange har efterlyst eksempler skønnede jeg, at det ville være gavnligt også at vise HVORDAN det kunne gøres.

#14:  Jeg er normaliserings-fanatiker.  Men det er spørgsmålsstilleren, ikke mig, der definerer problemstillingen.  Hvis han siger:  "Hvis jeg, trods de gode råd, vælger at bruge en enkelt tabel med 'tætpå'erne i en komma separeret liste, og jeg så efter en enkelt query vil have 'tætpå'erne navne skrevet ud, hvordan kan jeg så gøre det"  så er mit svar:  "Det kan du, hvis du i den komma separerede liste har 'tætpå'erne navne.  Ellers ikke."

Iøvrigt vil jeg gerne efterlyse et indlæg fra hrole.  Har du fået dit spørgsmål besvaret?  Hvad er din videre hensigt med tråden?

"Men det er spørgsmålsstilleren, ikke mig, der definerer problemstillingen." >> Det er da i det mindste en holdning!

Langt oftest - og lysende tydeligt i denne tråd - har spørgeren ikke de faglige forudsætninger for at kunne overskue sin egen problemstilling. Jeg ved godt, der i slutningen af 1960-erne var en bevægelse henimod den holdning, at elever/studerende selv bedst vidste, hvad de burde lære og hvordan. Allerede i begyndelsen af 70-erne var der dog rimelig bred koncensus om, at det blot var et forvrøvlet vildskud på Ungdomsoprøret.

I en tråd som denne ser jeg det således som min helt naturlige opgave at informere spørgeren om, hvad der i branchen regnes for best practice - og informere om sagligt begrundede alternative good practices. Men sådan kan man jo opfatte den samme virkelighed så forskelligt  =)

olebole, det du siger tror jeg ikke vi er uenige om.  Heller ikke hvad der i branchen regnes for best practice i tilfælde som dette.  (Du har da heller ikke udtrykt nogen faglige uenighed til min #8.)

At spørgeren så til syvende og sidst tager sine egne beslutninger kan vi vel heller ikke være uenige om. 

Og nu ville det være godt at høre fra spørgsmålsstilleren med henblik på at konkludere.

Som jeg læser, hvad du skriver, kan vores enighed ligge under en nordsvensk skovarbejders afhuggede lillefingernegl - men vi kan blive enige om det fornuftige i at vente på spørgeren  =)

Sidste mail jeg fik ang. denne tråd var ang. #11, derfor kommer mit svar først nu. Jeg har tænkt en del over jeres kommentarer og vælger at omstrukturere min db opbygning da den er uhensigtsmæssig, jeg har dog ikke den endelige løsning endnu.
Tråden lukkes her, tak for jeres input. Jeg fordeler 10 point til hver af Christian_Belgien, olebole og ronols.

Sidste mail jeg fik ang. denne tråd var ang. #11
Rediger profil -> nederst på siden har du Indstillinger  -> har du flueben i Smart e-mail
(Sender kun én e-mail pr. tråd indtil du har set tråden)
hvis du har det så fjern den, det kunne være årsagen

@hrole: Jeg samler ikke point, så det må være de to andres. Men tak for tilbudet  =)

ronols: tak, det var det. Smid svar

olebole: ok, men tak for hjælpen

jeg lukker, hvis du vil have point ronols må du lige give besked