---

Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle bestemte?
Altså uden at man skal til at nævne alle dem man vil SELECTE, men istedet
nævne dem man ikke vil SELECTE.

Mvh Stig

---

On Tue, 11 Dec 2001 14:52:58 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle bestemte?
>Altså uden at man skal til at nævne alle dem man vil SELECTE, men istedet
>nævne dem man ikke vil SELECTE.


Hmm.. det har ikke meget med mysql at gøre (det er standard sql)

det kan fx. gøres sådan:

   select * from table where not id in (xxx,yyy,)

kodeordet her er "not".

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

"Svenne Krap" <usenet@krap.dk> skrev i en meddelelse
news:ln4c1uorl70p73upb4u8qpm5uspn7l9id0@4ax.com...
> On Tue, 11 Dec 2001 14:52:58 +0100, "Stig Nørgaard Jepsen"
> <stigen@mail.dk> wrote:
>
> Hmm.. det har ikke meget med mysql at gøre (det er standard sql)
>
> det kan fx. gøres sådan:
>
> select * from table where not id in (xxx,yyy,)
>

Du snakker om rækker og Stig snakker om kolonner - to meget forskellige ting

Mig bekendt findes der ingen mulighed for at lave det Stig ønsker sig.
Hvor mange kolonner drejer det sig da om ??

Mvh
Martin

---

> Mig bekendt findes der ingen mulighed for at lave det Stig ønsker sig.

> Hvor mange kolonner drejer det sig da om ??

De tre første ud af cirka 30.

Problemet er jo selvfølgelig ikke større end at jeg bare kan la' være med at
bruge dem i PHP'en... eller simpelthen slette dem.
Men ville hellere ha' et output der kun består af de data jeg skal bruge.

Mvh Stig

---

"Stig Nørgaard Jepsen" <stigen@mail.dk> skrev i en meddelelse
news:3c161554$0$7906$edfadb0f@dspool01.news.tele.dk...
> > Mig bekendt findes der ingen mulighed for at lave det Stig ønsker sig.
>
> > Hvor mange kolonner drejer det sig da om ??
>
> De tre første ud af cirka 30.
>
> Problemet er jo selvfølgelig ikke større end at jeg bare kan la' være med
at
> bruge dem i PHP'en... eller simpelthen slette dem.
> Men ville hellere ha' et output der kun består af de data jeg skal bruge.

Det kan jeg godt forstå, det minimerer jo trafikken (netværk) en hel del,
hvis man kun får leveret det der er brug for.

30 felter i en tabel lyder, i mine ører, af mange. Har du overvejet af
normalisere din database ??

mvh
Martin

---

> > > Mig bekendt findes der ingen mulighed for at lave det Stig ønsker sig.
> >
> > > Hvor mange kolonner drejer det sig da om ??
> >
> > De tre første ud af cirka 30.
> >
> > Problemet er jo selvfølgelig ikke større end at jeg bare kan la' være
med
> at
> > bruge dem i PHP'en... eller simpelthen slette dem.
> > Men ville hellere ha' et output der kun består af de data jeg skal
bruge.
>
> Det kan jeg godt forstå, det minimerer jo trafikken (netværk) en hel del,
> hvis man kun får leveret det der er brug for.
>
> 30 felter i en tabel lyder, i mine ører, af mange. Har du overvejet af
> normalisere din database ??

Nu er jeg ikke nogen database-haj, men har da altid haft indtrykket af at
det ikke burde være det helt store problem med mange kolonner.
Hvad mener du med normalisere?

Jeg bruger denne tabel til at lave noget tekst på forskellige sprog i
forhold til andre tabeller.
Fx. kan det være en bildatabase(tabel), hvor der til hvert felt (fx
årgang,km-tal) skal bruges noget tekst.

mvh Stig

---

On Tue, 11 Dec 2001 15:57:54 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>Jeg bruger denne tabel til at lave noget tekst på forskellige sprog i
>forhold til andre tabeller.
>Fx. kan det være en bildatabase(tabel), hvor der til hvert felt (fx
>årgang,km-tal) skal bruges noget tekst.

Det er ikke 3NF, måske 2NF med lidt held.

Hvis du vil normalisere den op til 3NF (der er det mest almindelige),
skal du nok overveje at lægge alle tekster i en tabel med en tekst pr.
række og en type identifer og en sprogkolonne.

Typisk noget ala (PostgreSQL )

CREATE TABLE gui_texts
textid serial,
languageid int2,
textkey varchar,
textvalue varchar,
primary key(textid));

CREATE INDEX gui_texts_search on gui_texts(languageid,textkey);

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Jeg bruger denne tabel til at lave noget tekst på forskellige sprog i
> >forhold til andre tabeller.
> >Fx. kan det være en bildatabase(tabel), hvor der til hvert felt (fx
> >årgang,km-tal) skal bruges noget tekst.
>
> Det er ikke 3NF, måske 2NF med lidt held.

Hvaffornoget??

Hvad er det for noget xNF for noget..?
Hvor kan jeg læse om det?

> Hvis du vil normalisere den op til 3NF (der er det mest almindelige),
> skal du nok overveje at lægge alle tekster i en tabel med en tekst pr.
> række og en type identifer og en sprogkolonne.
>
> Typisk noget ala (PostgreSQL )
>
> CREATE TABLE gui_texts
> textid serial,
> languageid int2,
> textkey varchar,
> textvalue varchar,
> primary key(textid));
>
> CREATE INDEX gui_texts_search on gui_texts(languageid,textkey);

Hvorfor er det smart? :)

Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
pågældende tabel(fx.bil-tabel) i éen række.

Mvh Stig

---

On Tue, 11 Dec 2001 16:30:25 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>> Det er ikke 3NF, måske 2NF med lidt held.
>Hvaffornoget??
>
>Hvad er det for noget xNF for noget..?
>Hvor kan jeg læse om det?

3 NF er kort for tredje normalform.

Du kan læse om det i enhver bog omhandlende database-teori.

>> CREATE TABLE gui_texts
>> textid serial,
>> languageid int2,
>> textkey varchar,
>> textvalue varchar,
>> primary key(textid));
>>
>> CREATE INDEX gui_texts_search on gui_texts(languageid,textkey);
>
>Hvorfor er det smart? :)

3NF fordi det er fleksibelt og let at arbejde med.

Indexet så du får noget skrald i dine søgninger. Evt. kan du proppe
dem i nogle kategorier.

>Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
>pågældende tabel(fx.bil-tabel) i éen række.

Ja, men du kan ikke tilføje flere tekster uden at ændre tabellen og
dermed skal du til at rette igennem alt kildetekst.

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >> Det er ikke 3NF, måske 2NF med lidt held.
> >Hvaffornoget??
> >
> >Hvad er det for noget xNF for noget..?
> >Hvor kan jeg læse om det?
>
> 3 NF er kort for tredje normalform.
>
> Du kan læse om det i enhver bog omhandlende database-teori.

Yep. Har også fundet en del om det på nettet. Og kan godt se det smarte i
det :)
Men...

> >> CREATE TABLE gui_texts
> >> textid serial,
> >> languageid int2,
> >> textkey varchar,
> >> textvalue varchar,
> >> primary key(textid));
> >>
> >> CREATE INDEX gui_texts_search on gui_texts(languageid,textkey);
> >
> >Hvorfor er det smart? :)
>
> 3NF fordi det er fleksibelt og let at arbejde med.
>
> Indexet så du får noget skrald i dine søgninger. Evt. kan du proppe
> dem i nogle kategorier.

....giver det i alle tilfælde mere fart på søgningerne?
Sådan som jeg forstår det, så bygger den jo nogle ret store tabeller op når
man kører de små tabeller sammen...

> >Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
> >pågældende tabel(fx.bil-tabel) i éen række.
>
> Ja, men du kan ikke tilføje flere tekster uden at ændre tabellen og
> dermed skal du til at rette igennem alt kildetekst.

Jo... det kan jeg sådan set godt i den opbygning jeg har. Den eneste
begrænsning ligger jo så i om den kan lave nok tekster til felterne i en
anden tabel (fx. bil-tabel).

Mvh Stig

---

On Tue, 11 Dec 2001 22:28:40 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>> Du kan læse om det i enhver bog omhandlende database-teori.
>
>Yep. Har også fundet en del om det på nettet. Og kan godt se det smarte i
>det :)
>Men...

Dejligt, for det er smart :)

>...giver det i alle tilfælde mere fart på søgningerne?
>Sådan som jeg forstår det, så bygger den jo nogle ret store tabeller op når
>man kører de små tabeller sammen...

Store tabeller giver ikke nødvendigvis hastighedsproblemer.
Jeg arbejder til dagligt op imod en database for en tabel har
2.200.000 rækker (lidt mere men småpengene er ligegyldigt), der hver
er op til 4 kb bred.
En indexseret søgning returnerer een række i løbet af 38 msec.
Det er på en forholdsvis gammel maskine med 2 x PII-300, 768 MB RAM og
16Gb disk i et raid 5 med fire diske.

Men ideen med normalformer er ikke fart i arbejde, men rigtighed, der
giver fart i udvikling og ikke aflåser sig selv for muligheder.

Typisk vil man dog nogle steder afnormalisere for at få større fart,
men den måde du gør er (undskyld jeg er så direkte) småsindssyg.

>Jo... det kan jeg sådan set godt i den opbygning jeg har. Den eneste
>begrænsning ligger jo så i om den kan lave nok tekster til felterne i en
>anden tabel (fx. bil-tabel).

Huh. Ikke forstået.

Begrænsningen i din måde er for det første, kan databasen håndtere nok
kolonner i hver tabel (det burde ikke være noget problem) men det
andet og meget mere seriøse problem er følgende.

Hvis du arbejder som en professionel (dvs. med de dyre drenges
metoder), er du nødt til at anse ALT kode for forældet, hver gang du
ændrer i databasen da denne undgør fundamentet.

Dvs. tilføjer du en tekst til din side skal du tilføje en kolonne i
din tabel, dvs. hvis du vil gøre det rigtigt skal du igennem alle dine
x sider og tjekke enkeltvis at de opfører sig som forventet.
Hvis x nærmer sig 300 eller mere snakker vi hurtigt en mandemåneds
arbejde (dvs. 40-80.000 kroner i udgift).

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> Store tabeller giver ikke nødvendigvis hastighedsproblemer.
> Jeg arbejder til dagligt op imod en database for en tabel har
> 2.200.000 rækker (lidt mere men småpengene er ligegyldigt), der hver
> er op til 4 kb bred.
> En indexseret søgning returnerer een række i løbet af 38 msec.
> Det er på en forholdsvis gammel maskine med 2 x PII-300, 768 MB RAM og
> 16Gb disk i et raid 5 med fire diske.

Rart at høre! :)

> Men ideen med normalformer er ikke fart i arbejde, men rigtighed, der
> giver fart i udvikling og ikke aflåser sig selv for muligheder.
>
> Typisk vil man dog nogle steder afnormalisere for at få større fart,
> men den måde du gør er (undskyld jeg er så direkte) småsindssyg.

Yep, det er iorden at du siger det sådan. Jeg er jo nybegynder på dette
område :)

> >Jo... det kan jeg sådan set godt i den opbygning jeg har. Den eneste
> >begrænsning ligger jo så i om den kan lave nok tekster til felterne i en
> >anden tabel (fx. bil-tabel).
>
> Huh. Ikke forstået.

Heller ikke nemt at forstå :)

> Begrænsningen i din måde er for det første, kan databasen håndtere nok
> kolonner i hver tabel (det burde ikke være noget problem) men det
> andet og meget mere seriøse problem er følgende.
>
> Hvis du arbejder som en professionel (dvs. med de dyre drenges
> metoder), er du nødt til at anse ALT kode for forældet, hver gang du
> ændrer i databasen da denne undgør fundamentet.
>
> Dvs. tilføjer du en tekst til din side skal du tilføje en kolonne i
> din tabel, dvs. hvis du vil gøre det rigtigt skal du igennem alle dine
> x sider og tjekke enkeltvis at de opfører sig som forventet.
> Hvis x nærmer sig 300 eller mere snakker vi hurtigt en mandemåneds
> arbejde (dvs. 40-80.000 kroner i udgift).

Altså.. sådan som jeg har (havde) bygget det op, var det ikke nødvendigt at
tilføje nogen kolonner i tabellen - kun en ny række.

Mvh Stig

---

On Wed, 12 Dec 2001 16:23:12 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>Altså.. sådan som jeg har (havde) bygget det op, var det ikke nødvendigt at
>tilføje nogen kolonner i tabellen - kun en ny række.

huh ????

<snip fra news:3c162604$0$25358$edfadb0f@dspool01.news.tele.dk >
>Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
>pågældende tabel(fx.bil-tabel) i éen række.
<snip>

Det læser jeg som du har alle tekster i en række, dvs. data må være
adskildt i kolonnerne (og det er bad).

Kan du ikke for sjov poste en tabel-struktur, så vi snakker om det
samme :)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Altså.. sådan som jeg har (havde) bygget det op, var det ikke nødvendigt
at
> >tilføje nogen kolonner i tabellen - kun en ny række.
>
> huh ????
>
> <snip fra news:3c162604$0$25358$edfadb0f@dspool01.news.tele.dk >
> >Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
> >pågældende tabel(fx.bil-tabel) i éen række.
> <snip>
>
> Det læser jeg som du har alle tekster i en række, dvs. data må være
> adskildt i kolonnerne (og det er bad).

Netop.

> Kan du ikke for sjov poste en tabel-struktur, så vi snakker om det
> samme :)

Jo... jeg er godt nok begyndt at bygge om på det, men:
tablenameId - Language - Texttype - Field1 - Field2 - Field3 og op til
Field20.

På den måde kunne jeg hente et helt sæt tekster, tilhørende en bestemt
tabel, ned i en række.
Det var ikke sikkert at jeg skulle bruge alle Field-felterne... så tit var
der tomme...


Men jeg er ikke sikker på at jeg 100% forstår de forslag:
CREATE TABLE gui_texts
textid serial,
languageid int2,
textkey varchar,
textvalue varchar,
primary key(textid));

textid: er unikt autoincresing?
languageid: landesprogkode - fx. da, en eller se (i relation med med en
language-tabel?)
textkey: hvad bruger vi denne til?
textvalue: er det selve teksten?


Mvh Stig

---

On Wed, 12 Dec 2001 20:25:58 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:


>Jo... jeg er godt nok begyndt at bygge om på det, men:
>tablenameId - Language - Texttype - Field1 - Field2 - Field3 og op til
>Field20.

Uhh.. bad design.
Hvad er texttype til ?

>På den måde kunne jeg hente et helt sæt tekster, tilhørende en bestemt
>tabel, ned i en række.
>Det var ikke sikkert at jeg skulle bruge alle Field-felterne... så tit var
>der tomme...

Med risiko for at gentage mig selv :
Uhh.. bad design.

>textid: er unikt autoincresing?
>languageid: landesprogkode - fx. da, en eller se (i relation med med en
>language-tabel?)
>textkey: hvad bruger vi denne til?
>textvalue: er det selve teksten?

Husk på, jeg arbejder IKKE i mysql. Men jeg skriver da lige lidt
mysql-kode til dig :)

jeps, serial er en genvej til at lave en int4 (dvs. et mellemstort
tal), der "autoincrementer" (mere præcist sættes "not null" og default
sættes til nextval() af en passende sekvens).

create table gui_texts (
textid mediumint not null auto_increment,
sectionid mediumint not null,
languageid tinyint not null ,
textkey varchar(32),
textvalue text,
primary key(textid));

create index gui_texts_search_ix on gui_texts(sectionid, languageid);

meaning is as follows:

-textid skal kun bruges til at slette eller opdatere rækker med.
-sectionid er et tal, der bestemmer hvilken sektion du er i kunne være
hver side med sit eget sectionid eller kunne være en gruppe af sider,
der deler sectionid. Hvis du har meget få linjer kan du bare undlade
den. Formodentlig lidt ala din tablenameid.
-languageid er et tal (derfor -id) men kan laves om til en char(2)
hvis du fx. vil bruge da.
-textkey er "nøglen" for at få teksten ...
-textvalue er "selve tekstern".

når du så skal bruge teksten kan du gøre (pseudokode)

1) hent data fra tabel ( select * from gui_texts where sectionid = '1'
and languageid = '1')
2) kør igennem alle rækker og prop dem i et array i php (eller hvad
sprog du nu bruger), så dataene ligger
   $textarray[$textkey]=$textvalue;

Når du skal bruge teksten echo'er du bare $textarray["BRAND"] hvis du
skal have oversættelsen for mærke.

Capice ?

Det kan gøres endnu smartere ved at wrappe alt i en sprog-klasse, men
det har jeg ikke spalteplads (eller tid) til at forklare hvordan lige
nu og her...

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Jo... jeg er godt nok begyndt at bygge om på det, men:
> >tablenameId - Language - Texttype - Field1 - Field2 - Field3 og op til
> >Field20.
>
> Uhh.. bad design.
> Hvad er texttype til ?

Til at beskrive om det drejer sig om en labeltekst, en forklarendetekst
eller en hjælpetekst. (det var lige de bedste betegnelser jeg kunne finde på

Fx. hvis det var en tekst til en brugertabel så kunne -
labeltekst til feltet 'mobiltelefon' være 'Mobilos:'
forklarendetekst til 'password' være 'Skriv dit password her:'
hjælpetekst til 'ICQ' kunne være 'Du kan læse mere om icq på www.icq.com'

Hvis jeg stadig skal ha' dette med, ville du så ikke bare tilføje feltet
texttype som enum eller lign.?

> Capice ?

Ja, jeg tror jeg har fat i det efterhånden :)
Imorgen vil jeg forsøge at opbygge det på den måde, og se om jeg kan få det
til at køre.
Jeg takker mange gange for hjælpen! Uden sådan nogen som dig, ville jeg bare
ha' forsat med at lave dårlig design. (håber det her hjælper)

Kender du til et godt sted ude på nettet hvor jeg kan læse/lære noget om
databaser? Gerne en side hvor de bruger grafik til at forklare med.
Eller måske man bare skulle købe sig det der billige hæfte "Start på SQL"
til 69kr??

Mvh Stig

---

On Wed, 12 Dec 2001 22:46:31 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>Fx. hvis det var en tekst til en brugertabel så kunne -
>labeltekst til feltet 'mobiltelefon' være 'Mobilos:'
>forklarendetekst til 'password' være 'Skriv dit password her:'
>hjælpetekst til 'ICQ' kunne være 'Du kan læse mere om icq på www.icq.com'
>
>Hvis jeg stadig skal ha' dette med, ville du så ikke bare tilføje feltet
>texttype som enum eller lign.?

Huh, jeg er stadig ikke helt med, kan du ikke sende en række med reel
data og måske linket til siden, hvor det bruges ?


>Jeg takker mange gange for hjælpen! Uden sådan nogen som dig, ville jeg bare
>ha' forsat med at lave dårlig design. (håber det her hjælper)

Det er så lidt. Og desværre er der alt for mange med dårligt design.

>Kender du til et godt sted ude på nettet hvor jeg kan læse/lære noget om
>databaser? Gerne en side hvor de bruger grafik til at forklare med.

Glem ALT om nettet.. Lærdom kommer gennem trykt litteratur.
Tænk på, du kunne i princippet have lavet en webside, der fortalte om
database design. Hvad glæde tror du andre ville have haft af det ?

I en bog, sætter forlaget også sin røv på spil for rigtigheden af det
forfatteren skriver (jeg ved det, er selv i gang med at skrive en
fortsætter PHP-bog).

>Eller måske man bare skulle købe sig det der billige hæfte "Start på SQL"
>til 69kr??

Jeps, den er vist nok meget god (har ikke selv læst den).

Ellers udnyt julen til at ønske dig denne (det er på trods af titlen
en gudebog) :
http://www.amazon.co.uk/exec/obidos/ASIN/0201694719/qid%3D/026-7341090-2197204

Om den fås i DK, det ved jeg sgu ikke. (Men igen, hvem gider betale
danske priser for computerbøger)

Har jeg ret, når jeg antager, at du stadig går i skole ? Måske
gymnasiet ?

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Fx. hvis det var en tekst til en brugertabel så kunne -
> >labeltekst til feltet 'mobiltelefon' være 'Mobilos:'
> >forklarendetekst til 'password' være 'Skriv dit password her:'
> >hjælpetekst til 'ICQ' kunne være 'Du kan læse mere om icq på www.icq.com'
> >
> >Hvis jeg stadig skal ha' dette med, ville du så ikke bare tilføje feltet
> >texttype som enum eller lign.?
>
> Huh, jeg er stadig ikke helt med, kan du ikke sende en række med reel
> data og måske linket til siden, hvor det bruges ?

Kan kun gi' flere eksempler, da jeg ikke har lavet selve siden endnu :)


__labeltext:
Mobilos:
Password:
ICQ nr.:
Automatisklogon:
__forklarendetekst:
Skriv dit mobilnr. her:
Vælg et password:
Skriv dit ICQ nr. her:
Her kan du vælge om ¤site¤ automatisk skal logge dig på.
__hjælpetekst: (her kan jeg så vælge at lave en større forklaring til
feltet)
--- (ikke nødvendigt)
Password bruges når bla bla....
ICQ er bla bla bla...
Med automatisklogon behøver du ikke... bla bla...


Ved ikke om det er nemmere at forstå nu? :)

Mvh Stig

---

On Thu, 13 Dec 2001 10:20:52 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:

>Kan kun gi' flere eksempler, da jeg ikke har lavet selve siden endnu :)
>
>
>__labeltext:
>Mobilos:
>Password:
>ICQ nr.:
>Automatisklogon:
>__forklarendetekst:
>Skriv dit mobilnr. her:
>Vælg et password:
>Skriv dit ICQ nr. her:
>Her kan du vælge om ¤site¤ automatisk skal logge dig på.
>__hjælpetekst: (her kan jeg så vælge at lave en større forklaring til
>feltet)
>--- (ikke nødvendigt)
>Password bruges når bla bla....
>ICQ er bla bla bla...
>Med automatisklogon behøver du ikke... bla bla...
>
>
>Ved ikke om det er nemmere at forstå nu? :)

Er det kun een side ???

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Kan kun gi' flere eksempler, da jeg ikke har lavet selve siden endnu :)
> >
> >
> >__labeltext:
> >Mobilos:
> >Password:
> >ICQ nr.:
> >Automatisklogon:
> >__forklarendetekst:
> >Skriv dit mobilnr. her:
> >Vælg et password:
> >Skriv dit ICQ nr. her:
> >Her kan du vælge om ¤site¤ automatisk skal logge dig på.
> >__hjælpetekst: (her kan jeg så vælge at lave en større forklaring til
> >feltet)
> >--- (ikke nødvendigt)
> >Password bruges når bla bla....
> >ICQ er bla bla bla...
> >Med automatisklogon behøver du ikke... bla bla...
> >
> >
> >Ved ikke om det er nemmere at forstå nu? :)
>
> Er det kun een side ???

Hvad mener du helt præcist?
Jeg kommer selvfølgelig til at lave mange forskellige sider baseret på
dette.
Og deler det normalt op i flere sider.
Har fået det til at køre nu, og ville gerne vise dig et eksempel, men kører
det fra en webserver herhjemme. Vil lige prøve at gøre den tilgengængelig
ude på nettet i morgen.

Mvh Stig

---

Overså:
> Har jeg ret, når jeg antager, at du stadig går i skole ? Måske
> gymnasiet ?

Faktisk ikke... :)
Blev meget træt af mit tidligere erhverv og tog springet og er blevet
selvstændig... bruger nu min tid på at lære at programmere :)

/Stig

---

> >Sådan som jeg gør det nu får jeg alle de tekster jeg skal bruge til den
> >pågældende tabel(fx.bil-tabel) i éen række.
> <snip>
>
> Det læser jeg som du har alle tekster i en række, dvs. data må være
> adskildt i kolonnerne (og det er bad).

Lige en ting. :)
Fordelen (måske) ved at ha' et helt sæt tekster i en række (delt af
kolonner), var jo så at jeg kunne trække dem ud som et helt sæt.

Nu når jeg har bygget tabellen om, så jeg kun har tekster i en kolonne, så
får jeg jo selvfølgelig ikke trukket et sæt tekster ud på en gang, men
istedet en af gangen.
Før kunne jeg hente alle teksterne... fra fx. $row["field1"] ,
$row["field2"] , $row["field3"] osv...

Men nu skal jeg så kører igennem resultatet med mysql_fetch_array via en
whileløkke.
while($row = mysql_fetch_array($result)) {
$row["textvalue"];
}

Er der en eller anden måde jeg kan undgå dette på, og istedet få opbygget et
resultat som fx gør at man kan få feltet textkey til at være en key og
feltet textvalue til at være en value. Så man derved kan hente et sæt ud ved
at køre -
$row = mysql_fetch_array($result)
en enkelt gang. og herefter kan hente dataene -
echo $row["Bruger"].

Mvh Stig

---

On Thu, 13 Dec 2001 12:42:56 +0100, "Stig Nørgaard Jepsen"
<stigen@mail.dk> wrote:


>Lige en ting. :)
>Fordelen (måske) ved at ha' et helt sæt tekster i en række (delt af
>kolonner), var jo så at jeg kunne trække dem ud som et helt sæt.

Jeg ved ikke, om jeg synes det er en fordel .. det er kuriosum.. :)

>Nu når jeg har bygget tabellen om, så jeg kun har tekster i en kolonne, så
>får jeg jo selvfølgelig ikke trukket et sæt tekster ud på en gang, men
>istedet en af gangen.
>Før kunne jeg hente alle teksterne... fra fx. $row["field1"] ,
>$row["field2"] , $row["field3"] osv...
>
>Men nu skal jeg så kører igennem resultatet med mysql_fetch_array via en
>whileløkke.
> while($row = mysql_fetch_array($result)) {
>$row["textvalue"];
> }
>
>Er der en eller anden måde jeg kan undgå dette på, og istedet få opbygget et
>resultat som fx gør at man kan få feltet textkey til at være en key og
>feltet textvalue til at være en value. Så man derved kan hente et sæt ud ved
>at køre -
>$row = mysql_fetch_array($result)
>en enkelt gang. og herefter kan hente dataene -
>echo $row["Bruger"].


Du laver selv dit array:

altså

while($row=mysql_fetch_array($result)) {
   $mytext[$row["textkey"]]=$row["textvalue"];
}


// herfra kan du så bare

echo $mytext["bruger"];

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> Du laver selv dit array:
>
> altså
>
> while($row=mysql_fetch_array($result)) {
> $mytext[$row["textkey"]]=$row["textvalue"];
> }

Yep.. :)
Godt klar over at det var en løsning.
Men håbede egentlig at man kunne klare det på sql-siden... :)


Mvh Stig

---

"Svenne Krap" <usenet@krap.dk> wrote:

> Hvis du arbejder som en professionel (dvs. med de dyre drenges
> metoder), er du nødt til at anse ALT kode for forældet, hver gang du
> ændrer i databasen da denne undgør fundamentet.

Det kan godt være at der var sådan i starten af 80'erne, og det kan da også
være at der sider nogen enkelte tilbage og hakker i så gamle systemer, men i
dag foregår det simpelthen ikke på den måde.

> Dvs. tilføjer du en tekst til din side skal du tilføje en kolonne i
> din tabel, dvs. hvis du vil gøre det rigtigt skal du igennem alle dine
> x sider og tjekke enkeltvis at de opfører sig som forventet.
> Hvis x nærmer sig 300 eller mere snakker vi hurtigt en mandemåneds
> arbejde (dvs. 40-80.000 kroner i udgift).

Oven på din database programerer du noget business logic og alt adgang til
data foregår gennem denne logik. Skal strukturene opgraderes er det kun
klart afgrænsede dele af business logic der skal kikkes igennem, og ganske
få steder skal det rettes, testes og sættes i drift.

Hvis verden var som du beskriver kom ingen jo nogen steder....


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar & George Antheil

---

On Wed, 12 Dec 2001 23:08:28 +0100, "Ulrik Lunddahl"
<nospam037@lunddahl.dk> wrote:

>"Svenne Krap" <usenet@krap.dk> wrote:
>
>> Hvis du arbejder som en professionel (dvs. med de dyre drenges
>> metoder), er du nødt til at anse ALT kode for forældet, hver gang du
>> ændrer i databasen da denne undgør fundamentet.
>
>Det kan godt være at der var sådan i starten af 80'erne, og det kan da også
>være at der sider nogen enkelte tilbage og hakker i så gamle systemer, men i
>dag foregår det simpelthen ikke på den måde.

Så er det underligt, at jeg flere gange har været med til et komplet
codereview og en komplet feature-for-feature gennemgang af hele sitet
efter database-ændringer.

Og det var ikke kun lille mig, men vi var ti mennesker, der arbejde
med alt fra PHP, C++ og Java.

De fleste (mig ekskl.) er dataloger/datamatiker. De fleste har
trackrecords hos diverse store mobiltelefon-firmaers
udviklingsafdeling eller i nogle af de (dengang) så mægtige
web-bureauer.

>> Dvs. tilføjer du en tekst til din side skal du tilføje en kolonne i
>> din tabel, dvs. hvis du vil gøre det rigtigt skal du igennem alle dine
>> x sider og tjekke enkeltvis at de opfører sig som forventet.
>> Hvis x nærmer sig 300 eller mere snakker vi hurtigt en mandemåneds
>> arbejde (dvs. 40-80.000 kroner i udgift).
>
>Oven på din database programerer du noget business logic og alt adgang til
>data foregår gennem denne logik. Skal strukturene opgraderes er det kun
>klart afgrænsede dele af business logic der skal kikkes igennem, og ganske
>få steder skal det rettes, testes og sættes i drift.

Jeg er delvis enig, det var også derfor jeg brugte ordet anse. I den
virkelige verden kan man godt skønne, at ændringen er så ubetydelig,
at codereview er unødvendigt. Men hvis korrekthed er et mål, skal det
gennemføres.

>Hvis verden var som du beskriver kom ingen jo nogen steder....

Hvilket netop er grunden til man har database-freeze ca. halvvejs
mellem begyndelse af projektet og code-freeze for udviklerne.

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Tue, 11 Dec 2001 15:07:35 +0100, "Martin Elkjær Nielsen"
<martin@mecom.dk> wrote:

>Du snakker om rækker og Stig snakker om kolonner - to meget forskellige ting
>

Ja, jeg skal vist melde mig til et læsekursus igen snart :)

Kolonne mæssigt findes det mig bekendt ikke i standarden.

I øvrigt er "select * from" meget at fraråde, fordi man ikke kan se,
hvad personen prøver at opnå.

Mere "rigtigt" (tankegangsmæssigt, ikke reelt) er select

select attr1, attr2,attr3 ... attrN from ...

Så kan personer, der senere skal omdesigne tabellerne se, hvad du
ønsker at selecte ud.

:)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

> >Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle
bestemte?
> >Altså uden at man skal til at nævne alle dem man vil SELECTE, men istedet
> >nævne dem man ikke vil SELECTE.
>
> Hmm.. det har ikke meget med mysql at gøre (det er standard sql)
Nej, det har du vidst ret i :)

> det kan fx. gøres sådan:
>
> select * from table where not id in (xxx,yyy,)
Her vil resultatet da blive at jeg får output fra alle kolonner (med * efter
SELECT)?
Hvis jeg fx havde 20 kolonner fra a1 til a20, og gerne ville ha' output fra
alle undtagen a2, kunne jeg fx gøre sådan her:
SELECT a1, a3, a4, a5, a6, a7, a8 osv...
men istedet vil jeg gerne vælge alle undtagen a2 - noget lign.:
SELECT * (undtagen a2).

Er det helt umuligt?

Mvh Stig

---

In article <3c160f2adb0f@dspool01.news.tele.dk>, Stig Nørgaard Jepsen wrote:
> Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle bestemte?
> Altså uden at man skal til at nævne alle dem man vil SELECTE, men istedet
> nævne dem man ikke vil SELECTE.

SELECT * FROM tabel WHERE attr != "test";

--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk

---

"Jesper Krogh" <jesper@linuxpusher.dk> skrev i en meddelelse
news:slrna1c4mk.3j1.jesper@luke.kollegiet...
> In article <3c160f2adb0f@dspool01.news.tele.dk>, Stig Nørgaard Jepsen
wrote:
> > Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle
bestemte?
> > Altså uden at man skal til at nævne alle dem man vil SELECTE, men
istedet
> > nævne dem man ikke vil SELECTE.
>
> SELECT * FROM tabel WHERE attr != "test";

Er det MySQL specifikt, det virker ikke på Oracle....eller også gør jeg
noget forkert ??
En Where betingelser opererer jo normalt på rækkeniveau.


Martin

---

In article <EvoR7.95$Qv5.7109@news.get2net.dk>, Martin Elkjær Nielsen wrote:
>
> "Jesper Krogh" <jesper@linuxpusher.dk> skrev i en meddelelse
> news:slrna1c4mk.3j1.jesper@luke.kollegiet...
> > In article <3c160f2adb0f@dspool01.news.tele.dk>, Stig Nørgaard Jepsen
> wrote:
> > > Kan man lave en sætning der SELECT'er alle kolonner undtagen nogle
> bestemte?
> > > Altså uden at man skal til at nævne alle dem man vil SELECTE, men
> istedet
> > > nævne dem man ikke vil SELECTE.
> >
> > SELECT * FROM tabel WHERE attr != "test";
>
> Er det MySQL specifikt, det virker ikke på Oracle....eller også gør jeg
> noget forkert ??

I Oracle skal du vist bruge ' i stedet for "

> En Where betingelser opererer jo normalt på rækkeniveau.

Ved nærmere eftersyn gør den heller ikke det han spørger om...
Jeg tror vi skal have en lidt dybere beskrivelse af problemet.

--
../Jesper Krogh, jesper@linuxpusher.dk
webshop: http://www.linuxpusher.dk

---

"Jesper Krogh" <jesper@linuxpusher.dk> skrev i en meddelelse
news:slrna1c5mf.3j1.jesper@luke.kollegiet...
> In article <EvoR7.95$Qv5.7109@news.get2net.dk>, Martin Elkjær Nielsen
wrote:
>
> I Oracle skal du vist bruge ' i stedet for "

Tak

>
> > En Where betingelser opererer jo normalt på rækkeniveau.
>
> Ved nærmere eftersyn gør den heller ikke det han spørger om...
> Jeg tror vi skal have en lidt dybere beskrivelse af problemet.

Som sagt, så tror jeg desværre ikke det er muligt i SQL. Men vi får se

Martin