Mere end 255 felter i en Paradox tabel

Har du seriøst brug for >255 felter pr. post?!  Det virker helt utroligt.  Er du sikker på at du ikke kan splitte det ud i flere tabeller - hvilket jo iøvrigt nærmest er hele iden med relations databaser.

Hvor meget kender du til normalisering af databaser?  Skal du ha\' et lille eksempel?

Peter

Jeg skal ikke kunne sige om der er nogen vej omkring den begrænsning, men hvis du har brug for 350 felter så tror jeg umiddelbart ikke at du har oprettet din database på den bedst tænkelige måde.

Du vil altid kunne fordele dine 350 felter på 2 tabeller (eller flere). Det eneste minus at du skal håndtere at de to holdes i sync.

Prøv evt. at beskrive \"hvorfor\" du har brug for 350 felter i samme tabel !?

Peter >> Ja det er helt seriøst at jeg har brug for så mange felter. Det er til en teknisk styring, hvor der er et hav af parametre for et antal følere og ventiler, der skal kunne justeres på.

Har overvejet at benytte en relationsdatabase, men syntes det bliver lidt besværligt for vores kunder at lave f.eks. backup mv. Nå data er splittet ud i flere databaser.

At du har flere tabeller i Paradox kan jeg ikke se skulle være et problem da Paradox i forvejer strør om sig med filer (pr. index og pr. det-ene-og-det-andet).

Navnlig hvis din applikation skal anvendes i et netværks/flerbruger -miljø kan jeg varmt anbefale InterBase som nu er OpenSource/Freeware. I backup øjemed udmærker denne sig ved at hele databasen er samlet i en eneste fil som nemt kan \"back\'es up\" og \"restore\'s\".

Jeg skal ikke kunne sige om InterBase også er ramt af \"255 felter pr. tabel problemet\" - men i såfald så vil udvejen være at splitte den op i flere. Ved hjælp af \"foreign keys\" og/eller triggers kan du nemt holde de 2 i sync med hinanden.

Paradox ER en relations database!

Paradox har iøvrigt alle sine filer placeret i et enkelt directory.  Backup er således blot et spørgsmål om at backup\'pe hele dette dir.

Peter

Forklar i øvrigt lige (kort) lidt mere om din opgave.  Du nævner fx. at du har ventiler og følere.  Disse komponenter har, bortset fra at de fx. kan sidde på samme \"anlæg\", reelt intet med hinanden at gøre og det vil således ikke være rimeligt at placere dem i samme tabel. 

Løsningen vil her at have en tabel over \"anlæg\".  Tabellen vil indeholde et unikt nøglefelt for anlæget, fx. AnlægsNr, samt yderligere specifik information om anlæget, fx. navn, placering mv.
Du vil så lave en tabel for de ventiler der er placeret i et anlæg.  Tabellen vil som nøglefelt have en kombination af AnlægsNr (som dermed er en fremmednøgle) og et VentilNr.  Kombinationen skal være unik i denne tabel.  Desuden kan de enkelte poster i tabellen indeholde informationer specifikt om den pågældende ventil. 
Tilsvarende laves en tabel over følere - nøglefelttet er her AnlægsNr + FølerNr.  osv osv.
Det smarte ved dette system er, at man kan oprette, slette mv. poster i en tabel, fx. ventil tabellen, uden at dette har nogen indflydelse på føler tabellen.  På samme tid har du drastisk nedskåret antallet af felter i de enkelte tabeller - dette er et mål i normaliserings tankegangen. 

En DB normaliseret ud i sin yderste konsekvens vil blot indeholde tabeller bestående af to felter.

Peter

Peter >> Mit program kalder op til en kunde via et modem. Ude hos kunden er der monteret ventiler, følere mv.

Der er oprettet en record i databasen for hver kunde, da indstillingerne af f.eks. set-punkterne for installationerne er forskellige.

Jeg er uenig med dig i at komponenterne i anlæget \"ikke har noget med hinanden at gøre\". Det vil være uhensigts-mæssigt at skulle stykke en kundes installation sammen af data fr måske 50 forskellige tabeller.
Hvordan skal jeg sikre mig at disse tabeller er 100% synkrone, og bliver ved med at være det?

Det kræver at der oprettes en ny record i hver eneste tabel, hver gang der oprettes en ny kunde.
Lige ledes skal jeg være 100% sikker på at alle records fjernes igen når en kunde slettes.

Nej nej - du har misforstået noget.

Hvis du fx. har en kunde, der ikke har nogen ventiler men masser af følere, så vil der være EN post i kunde tabellen (det var den jeg før kaldte anlæg).  Der vil være 0 poster i ventil tabellen og en post pr. føler i føler tabellen.  I en ralations database er der kun poster for reelle data - og den kan uden problemer udvides med et dynamisk antal poster, hvis antallet af ventiler/følere mv ændrer sig.  Det er lige modsat i en flad database fil, som den du har i tankerne, hvor du på forhånd, dvs. på design tidspunktet, skal bestemme hvor mange ventiler/følere de enkelte kunder kan/må ha\'.  Hvad gør du hvis kunden ingen ventiler har? - fylder posternes felter med en dummy string?  Hvad hvis der lige pludseligt er behov for plads til flere ventiler? - Re-designer hele databasen og dermed din application?  For at undgå disse problemer er du på forhånd nødt til at designe databasen således at den er \'stor nok\', hvilket er ens betydende med redudante data og spild af resourcer som plads og tid.
En relations database er netop designet til at indeholde \'synkrone\' data, også kaldet referential integrity.  Forskellige regler i database opbygningen gør, at du ikke kan komme ud for situationer, hvor du sletter en post i kundetabelen således atder kommer herreløse poster i fx. ventil tabellen.  Eller nærmere: der er regler for om sletningen skal nægtes, om alle afhængige poster også skal slettes (cascade slætning) osv.  Det vil desuden ikke være muligt at indsætte den samme post to gange i relations DB, idet man derved får en keyviolation.
Du skal faktisk ikke tænke så meget på det med synkronisering, idet dette kommer mere eller mindre af sig selv.

Det er ikke svært at \'sammenstykke\' data fra flere tabeller, idet der er \'opfundet\' et fantastisk standard sprog til formålet: SQL.  Med SQL laver man et udtræk af et vilkårligt antal tabeller, efter søge kriterier du selv sætter op, og alle fundne poster afleveres som om det var fra en tabel. 

Her følger lige et hurtigt eksempel.  Antag at du har følgende tabeller.

KUNDE:
KundeNr  Navn    TelefonNr  ... ... ...
0001    KundeX  555-123 456
0002    KundeY  123-323 125
0003    KundeZ  542-232 243

VENTIL:
KundeNr VentilNr Setpunkt
0001    0001      4711
0001    0002    12343
0001    0003      1211
0002    0001      1211
0002    0002      322
0003    0001      1211
0003    0002      1212
0003    0003      333
0003    0004    23432

Nu laver vi lige et udtræk, hvor vi ønsker at se hvilke ventiler, og disses data, Kunde nr 1 har.  For eksemplets skyld ønsker jeg også at se Kundens navn og telefon nr. i hver linie i trækket.  SQL udtrykke bliver:

SELECT Navn, TelefonNr, VentilNr, Setpunkt
FROM KUNDE, VENTIL
WHERE (KUNDE.KundeNr = 0001) And (KUNDE.KundeNr = VENTIL.KundeNr)

Følgende vil være det resulterende output:
Navn    TelefonNr  VentilNr  Setpunkt
KundeX  555-123 456 0001      4711
KundeX  555-123 456 0002    12343
KundeX  555-123 456 0003      1211

Bemærk, at selv om navnet på Kunden indgår tre gange i dette udtræk, så er det altså kun lagret et sted og der er således kun et sted der skal rettes hvis noget skal ændres.

SQL giver også muligheder for at sortere sine outputs, fx:

SELECT Navn, TelefonNr, VentilNr, Setpunkt
FROM KUNDE, VENTIL
Where KUNDE.KundeNr=VENTIL.KundeNr
ORDER BY TelefonNr


Delphi

Delphi >> Ok du får point selv om jeg ikke vil bruge dit svar.
Det jeg ville lave var en ganske simpel data-base. Jeg syntes SQL og en relationsdatabase er skudt langt over målet.
En flad database fil passer meget bedre til opgaven. Jeg gemmer bare nogle af mine parametre som binær-data i et BLOB-felt istedet for at have felter til dem alle.

Tak for dit svar alligevel.

Hvis du er inde på det spor, så bør du helt droppe tanken om at benytte en database.  Brug bare en helt almindelig binær fil.  Gem dine data i en (array of) record som du loader/gemmer i en *.DAT fil (Evt. INI file, hvis den skal kunne læses med menneske øjne).

Peter

delphi >> Jeg vil jo gerne benytte database-komponenterne til at håndterer indtastning/søgning mv. af de administartive data som kundens navn, adresse, telefon mv.
Det er langt lettere end selv at skulle lave det hele fra grunden.
Ellers havde du ret.