Query med kommastreng

psuedo:

var sql;

sql = "select * from tabel "
foreach(int s in $streng)
{
sql +="where colonne = " +s;
}

nåå det er en streng.. øhmm brug

Psuedo:
for(int i = 0; $streng.split(,).length; i++)

her er string.split php http://www.codeguru.com/forum/showthread.php?s=&threadid=292394

Er ikke lige helt med, giver det mig ikke kun noget retur hvis mit felt matcher præcis en af de værdier du hiver ud af min streng?

jo sorry


for(int i = 0; $streng.split(,).length; i++)
{
if(i = 0 or $streng.split(,).length = 1)
sql +=" where colonne = " +s;
else
sql +=" OR where colonne = " +s;
}

Echo sql;

i=0 er vist nok i den ifsætning

lol..


sql +=" OR colonne = " +s;

/JJ

for(int i = 0; $streng.split(,).length; i++)
{
if(i = 0)
sql +=" where colonne = " +s;
else
sql +=" OR colonne = " +s;
}

Det er en meget dårlig database struktur at have et felt med flere værdier. Et felt bør kun indeholde en værdi og ikke mere.

Jokkejensen, beklager ulejligheden men kan du forkrome din kode lidt, kan ikke rigtig få den samlet så den funker.

hehe jeg kender ikke til php..

Men noget ala:

$streng = '1,8,3';
$streng_array = $streng.split(',');
$i = 0;


$sql = "Select * from tabel where "
for($i=0; $streng_array.lenght; i++)
{
if($i = 0)
$sql+= "colonne = " + $streng_array[$i];
else
$sql+= "or colonne = " +$streng_array[$i]
}

Der er sikkert en masse fejl men har aldrig brugt php, der er sikkert en der lige kan fikse det..

/JJ

for($i=0; $streng_array.lenght; $i++)

måske : $streng_array = array($streng.split(','));

Nej synes godt jeg kunne fornemme det :) Men nice nok.. Men da colonne jo kan indholde f.eks. 1,9,3 skal jeg vel vende den og bruge IN, altså $streng_array[$i] IN (colonne), men bliver den for tung?

Kan der være 2 decimal tal ?

altså 10 og 22 ?

/JJ

(men mange til mange relationer løses oftes ved at normalisere)

Yes, det kan den godt.

okay - så bliver det straks noget mere komplext..

Er du sikker på du ikke skal rulle lidt tilbage i din udvikling og gøre som dkfire foreslår, altså normalisere den ned på et fornuftigt niveau?

/JJ

Du kunne lave noget ala:
SELECT * FROM tabelnavn WHERE felt IN( $streng )

Eller hvis jokkejensen's eksempel skal virke:

$streng = '1,8,3';
$streng_array = explode(',', $streng);

$sql = "SELECT * FORM tabelnavn WHERE";

for($i = 0; $i < count($streng_array); $i++)
{
    if($i == 0){
        $sql .= "felt LIKE '%".$streng_array[$i]."%'";
    }else
        $sql .= "OR felt LIKE '%".$streng_array[$i]."%'";
}

jokkejensen > Desværre too late for that :)
dkfire > Hvad vil du anbefale LIKE eller IN, hvad trækker mindst i db?

Jeg tror ikke IN virker, ellers er det nok den som er hurtigst og bedst, du vil med LIKE få for mange forskellige muligeheder, og så vil den ikke kunne kende forskel mellem 21 og 1 hvis du søger efter 1.

Men det helt rigtige måde er at normalisere dine tabeller så du ikke har flere værdier i samme felt. Du vil få alt for mange problemer med flere værdier i samme felt.

Som sagt kan jeg desværre ikke ændre det, men må prøve mig lidt frem.. Tror nu godt IN skal virke, men det bliver selvfølgelig ikke den optimale løsning.

Hvordan kan det være du ikke kan ændre det, hvis jeg må spørge ?

Det må du ikke ;)

Du vil få et kæmpe problem hvis og når du skal opdatere dit felt med en ny værdi.

Det bliver heldigvis intet problem i den store sammenhæng.. Har kun det her ene lille issue.. Men den er vidst snart løst.

Okay, jeg kan ikke lige følge dig i at det IKKE bliver et problem. Du skal lave så meget ekstra kode for at tilføje eller fjerne et tal fra dit felt at det slet ikke giver mening at bibeholde den struktur for dine tabeller. Og hvis du alligevel begynder at tænke på hvad der er hurtigst for databasen ang. LIKE og IN, så skal du også tage i betrækning at din struktur bestemt også har indflydelse på hvor hurtig og effektiv din database er.
At have en database struktur, i et større system, som i det mindste ikke er normaliseret til grad 2 er fuldstændig tåbeligt.

Jamen hvis jeg ikke skal tilføje eller fjerne fra mit felt?

Hvordan går du så værdier i dit felt ???

opsamling fra form (checkboxe), når strengen er skabt kan den ikke ændres..

Har du test om IN virker ??

<ole>

Det ligner en uhensigtsmæssig tilgang. Umiddelbart kunne jeg forestille mig, det bliver en ekstremt skidt performende forespørgsel med alle de LIKE's eller IN's. Uden at vide, hvad du præcist skal lave, er det dog svært at anbefale et alternativ

/mvh
</bole>

Jamen da jeg har omkring 3500 gode grunde (poster i db), til ikke at ændre strukturen i databasen, ledte jeg egentlig bare efter en query som nogenlunde kan klare presset. Håbede at en mysql guru kunne komme med et godt løsningsforslag, men det lader til at der ikke er andre forslag end LIKE, eller IN?

Jeg er også meget i tvivl om at IN virker efter hensigten. Og med LIKE kan jeg kun give olebole ret, det vil slet ikke være godt for serveren. Men som sagt der findes ingen alternativer når opbygningen ikke er normaliseret.

Jamen der findes jo ikke nogle lette måder, da man jo ikke skal designe sine tabeller på den måde. Hvorfor lave en funktionen som ikke skal bruges.

wolstrup >> Nej, det er 3500 dårlige grunde  ;o)
Hvis du laver et lille script, der ændrer din DB, tager det næppe mere end et minut at køre sciptet på DB'en

Jamen der er ingen tvivl om at hvis jeg havde mulighed for at rive hele skidtet ned og starte forfra, ville det være den eneste rigtige løsning. Er desværre ikke så privilegeret, så må have det bedste ud af det med den database der nu foreligger :)

Hehe ole du har ret.. Meen skal jo så hele koden igennem for at se om ændringen laver løjer i den andre steder, og skal lige sige at der er en pænt stor del af koden som ikke er udforsket endnu. Puha, er der virkelig ingen anden vej :)

Nej desværre, det er derfor meget vigtigt at have den rigtige struktur på databasen fra start, og have tænkt alt igennem inden der kodes noget som helst php.

Ja dkfire, tror jeg vil sende denne korrespondance til den tidligere udvikler med din seneste kommentar highlighted :) Der var ellers lige en lille frækkert her man kunne kigge nærmere på http://www.thescripts.com/forum/thread141874.html

Tak skæbne, hvis du skal udføre den query for en tabel med 3500+ rækker, så tror jeg hurtigt du kommer til at lægge din server ned.

"tror jeg vil sende denne korrespondance til den tidligere udvikler" >> "den tidligere indvikler" ville nok være en mere præcis beskrivelse  ;o)

Programmering foregår langt hen ad vejen i hovedet - derefter på papir med streger, pile kasser og nussede kommentarer - derefter i et (evt. grafisk) dokumentations program.

Når alt er færdigprogrammeret, skal applikationen bare færdiggøres ved at skrive koden i en tekst editor, så den kan afvikles på serveren  :)

- men alt formange begynder der, hvor applikationen burde være færdigprogrammeret ... hvilket præcis er årsagen til, du nu sidder med den gang sovs  :o|

"...vigtigt at have den rigtige struktur på databasen fra start, og have tænkt alt igennem..."  Jah, der skal nok findes et par små, og trivielle applikationer, hvor det kan lade sig gøre. Vi andre forsøger derimod at designe ud fra forventningen om forandring, og bygger systemet med moduler/lag/mønstre (kært barn ...) så en ændring i fx tabelstrukturen blot giver få og lokale ændringer i koden. Så har man fornøjelsen at lære af sine erfaringer.

erik: det er vel også en måde at have den rigtige strukturer sin database/kode.

Jeg er sikker på vi i alt væsentligt mener det samme, så lad os ikke komme ud i noget med diminutive insekters gøren og laden i indbyrdes tvekønnet samkvem (spm/822750)  ;)

Det hjælper ikke spørgeren, som er den eneste der kan afgøre om en tablescan (lineær søgning) ved hver forespørgsel kan forsvares, eller om tiden er bedst brugt på en omkodning.