Normaliserings spørgsmål

Det kan jo også ske, at samme filnavn ligger på flere af maskinerne. Det kunne f.eks. være filerne i C:\Windows. Der kan så eventuelt være forskellige datoer. Men med en måske lidt uortodoks link-tabel, kunne dette også laves i databasen. Så ville det komme til at se sådan ud:

Autonummerering|Ip|Computernavn|Type| - computertabellen

compId|Dato|filId| - linktabellen

filId|Sti|Filnavn|Extension|Size| - filtabellen

compId i linktabellen er stadig fremmednøgle til computertabellen. filId i linktabellen er fremmednøgle til filtabellen, hvor filId er også er en autogenereret primærnøgle.
Dato er flyttet over i linktabellen, for at man stadig kan angive en dato til hver enkel fil på hver enkel computer.

JA! Helt bestemt. Og det er også lettere når en maskine får nyt IP nummer.

Det lyder meget fornuftigt.

Dog kan jeg ikke rigtigt lidt IP - kører i med fast IP adresser, eller ...?

Rasmus' forslag er godt  - hvis du kan styre ens filer. På den vis slipper du også billere i backup (der bør måske være en checksum - bare så du ikke får taget backup af den éne virus fil der er og så distribuere den til alle de andre.)

Nej, vi kører med dynamiske IP-adresser...så det blir lidt svært på den måde

Jeg kan ikke lave en computertabel som er "statisk" da det vil forekomme at samme computer kan have forskellig ip...
Men stadig er det jo relativt sjældent at en IP skifter

dadane, det er ikke selve filerne jeg har liggerne. Det er blot filnavn + sti osv. så jeg kan være ligeglad med virainficerede filer

Den her filId, skulle det være en autonummerering?
Eller hvordan skal jeg identificere dem?

Jeps, det var tænkt som autonummerering

Hmm det blir jo så bare lidt svært eftersom filerne bliver slettet og skrevet ned i databasen igen ved hvert scan.
Dvs. filerne får et nyt autonummer hver gang?
Holder det?

Det mest smarte ved scanninger ville være kun at skrive ændringerne i databasen i stedet for at starte forfra hver gang. Men jeg kan godt se, at der er et problem der, hvis en fil er blevet slettet på en af maskinerne mellem to scanninger.
Der må jeg sige, at jeg ikke lige har noget forslag...

Mit problem bliver jo også at vedligeholde den tabel der identificerer de enkelte computere da vi ikke har faste IPer...Så skal jeg lave noget med hvis ip/compnavn kombination findes skal der kun opdateres i filtabellen, ellers skal der opdateres i begge tabeller og compId i filtabellen skal nu knyttes til det nye autonummer der bliver tildelt når den nye ip/compnavn bliver lagt i i computertabellen.
Bliver det ikke noget værre roderi mon?
Spørgsmålet er om det overhovedet kan betale sig...Jeg kan simpelthen ikke gennemskue det

Der kommer jo alligevel til at være en trilliard tupler i den database, og feltet "sti" er defineret som en lang tekst. Altså en blob. Alene det felt kommer jo til at tage ufatteligt meget performance...Så måske så¨meget at det er ligemedet at ip/compnavn som er to almindelige tekstfelter og type som er en int, bliver gentaget en masse gange.
Hvad siger I?

Tjah...evt. kunne ip vel udelades? Forudsat, at alle maskiner har et computernavn.

jamen det har de, men alligevel synes jeg bare det er sådan liiiidt du ved at lave ID på blot et computernavn. Så kunne man måske lave det på MAC adressen...men folk skifter jo konstant computere og dermed netkort....og så er man jo ligevidt

Hvorfor er stien en blob? Så vidt jeg husker (ret mig hvis jeg tager fejl) tillader hverken windows, dos, linux eller macos mere end allerhøjest 255 tegn (tror det ofte er det halve). Så en varchar skulle vel være alt rigeligt.

Og jeg tror stadig der er en del at spare ved at normalisere. Både i plads og i performance.

Performancemæssigt er spørgsmålet dog også - hvad gør du mest? Indsætter eller søger?

Endeligt kan man selvfølgelig blive helt praktisk og sige "if it works don't fix it".
Lad lortet køre inditl det bliver en nødvendighed at ændre noget.

Så bliver du også hurtigere færdig ;)

Du er en klog mand dadane :)
Principperne er da i orden :P
Der vil køre langt flest indsættelser eftersom der kun bliver administratortne dvs. 5-10 mennesker der kommer til at søge i den, og over 2000 computere hvis filer vil blive indsat.
Hmmm ja..ser ud til du har ret i det med sti-længden. Jeg troede at det kun var mappenavnene der max måtte være 255 karakterer, og der måtte være vilkårligt mange mapper...Men kunne man ikke forestille sig at det snart bliver ændret?

Tjoeh, det er altid svært at forudsige hvilke ændringer andre laver, - men mon dog?

Bare af nysgerrighed, - hvad skal det bruges til?

Licenstjek? (Hvor mange har installeret program X version Y)
Seriøsitetstjek (et enkelt billede er o.k. - men 537 billeder som alle starter med XXX er ikke)?

Ja, det må nok være det nederste.
Det skal give administratorerne et overblik over hvilke filer der flourerer rundt i virksomheden...Om filerne ligger korrekt og om folk ikke sidder med et hav af piratkopier og ting og sager på deres computer...

Hele systemet har jeg faktisk lavet..og testen har kørt i et stykke tid i en afdeling på 30 ansatte....Der er så også nogle servere med osv. Men der ligger nu knap 1 million tupler i tabellen

så det er ret store mængder data at arbejde med...og også derfor jeg begyndte at spekulere lidt.
Ikke fordi jeg havde da også tænkt de tanker inden jeg gik igang...men ville gerne have et produkt hurtigt på bordet
Nu tænkte jeg bare at jeg for min egen skyld måske burde lave databasen stabil også, så jeg ikke får allemulige irriterende vedligeholdelsesproblemer sidenhen

Hmmm...lidt off topic, men det er vedligeholdelse, man tjener penge på...hehe ;o)

Jeg tror at jeg ville lave det som:

computer
--------
navn,PK
type
sidsteIP
sidstescan

fil
---
id,PK,autogenerate
computer,FK->computer
filsti
filnavn
filext

Begrundelse:
* jeg tror ikke at du kan detecte hvis en computer skifter navn og så er computerid
  overflødigt
* sidsteIP giver også mening med DHCP
* sidstescan på computer tillader at scanne computere på forskelligt tidspunkt
  men uden at gemme en tid per fil
* de 4 felter i fil kunne faktisk godt være en sammensat PK men det synes jeg
  er for bøvlet derfor en autogenrated id

Hov - der skal vist lige tilføjes et size felt til fil tabellen.

Jeg tænkte på om det evt. ville være smart at lave en form for checksum på sti+filnavn+extension. Så kunne man på en eller anden måde udnytte det for ikke at skrive de samme stier 1000 gange.
Ville det være smart?

Det kunne det sagtens være.

Så ville filsti erstattes af stiid.

Du ville spare en del plads. Og få en JOIN mere i mange queries.

hmmm ja...hvordan ville man skulle lave det?
Findes der algoritmer til at lave checksumme?
Og hvad skulle jeg så sætte ind i databasen? Og hvad skulle jeg evt. lave checksum over?

Jeg ville så bare lave:

computer
--------
navn,PK
type
sidsteIP
sidstescan

sti
---
id,PK
filsti

fil
---
id,PK,autogenerate
computer,FK->computer
stiid,FK->sti
filnavn
filext
size

Ville du så lægge fx. checksummen for stien som "filsti" inde i sti tabellen?
Kunne man ikke med fordel også lave noget checksum på filnavn/ext/size tilsammen? og lægge de informationer ud i en tabel for sig, med en autogenereret ID som PK og i filtabellen skulle der så være en filID som FK der forbandt til den nye filtabel. Så man fik noget ala:

computer
--------
navn,PK
type
sidsteIP
sidstescan

sti
---
id,PK
checksum på(filsti)

fil
---
id,PK
Checksum på(filnavn,filext,size)

samling
---
id,PK,autogenerate
computer,FK->computer
stiid,FK->sti
filid,FK->filnavn,type og størrelse

Efter lidt eftertanke så tror jeg ike påd en checksum ide. En FK til sti må
være det rigtige.

Hvad mener du?

At det er unødvendigt at lave checksumme?

Ja

hvorfor mener du det?

Du mener data basen selv finder ud af at overholde den referentille integritet hvis jeg bare sletter/indsætter og opdaterer kaskadevis eller hvad?

En FK stiid er betydeligt mere effektivt end den checksum

-------------------------

Nogen databaser understøtter cascade delete. Andre ikke.

okay, det har du jo nok ret i.
Mht. at indsætte nye logs eller hvad man nu skal kalde dem i samlingstabellen. Så er jeg vel nødt til først at hive alle stier ud af sti tabellen, og derefter checke hvilken en jeg skal referere til vha. sammenligning af stier.
eller kan man på en eller anden måde lave en join i en insert eller noget andet smart ?

Jeg ville lade stier være PC specifikke d.v.s. at når man processer en PC så sletter
man alle stier til den PC og opretter dem alle igen.

Men der skal jo kun være en sti der hedder fx. C:\winnt
På den måde kan alle der har en sådan sti referere til den...og der kan derved spares kolossale mængder data...Det er da skide smart

Hvis stierne var pc-specifikke ville man jo ikke spare specielt meget

Kan du se hvad jeg gør galt her?
Jeg vil bare hive en int ud af databasen

                string sql3;
                printf("debug1");
                sqlstr="SELECT ID FROM Files";
                printf("debug2");
                stat = SQLExecDirect(stmt,(SQLCHAR *)sqlstr,strlen(sqlstr));
                  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO))
                  {
                      printf("Error in ExecDirect %i og %i\n",stat,SQL_ERROR);
                  }
                printf("%i",linectr);

sqlstr er en char*

Jeg connecter på samme måde som du viste mig engang
http://www.eksperten.dk/spm/455186

Ja.

Når du scanner skal du kun indsætte 1 række i sti og X rækker i fil.

jeg prøver lige at sende en lidt mere komplet kode


#include <stdio.h>
#include <stdlib.h>

#include <windows.h>
#include <sql.h>
#include <sqlext.h>

char* constr =  "Driver={Microsoft Access Driver (*.mdb)};Dbq=\\\\ntbrb02\\databaser\\filscantest.mdb;Uid=Admin;Pwd=;";
char* sqlstr = "SELECT ComputerNavn FROM Computers";

int main(int argc, char *argv[])
{
  SQLHENV Environment;
  SQLHDBC DataBaseConnect;
  SQLHSTMT stmt;
  SQLRETURN stat;
  int i,il,sl,outconlen;
  char s[100],outconstr[1024];
  stat = SQLAllocEnv(&Environment);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in AllocEnv\n");
  stat = SQLAllocConnect(Environment,&DataBaseConnect);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in AllocConnect\n");
  stat = SQLDriverConnect(DataBaseConnect,NULL,
                    (SQLCHAR *)constr,(SQLSMALLINT)strlen(constr),
                    (SQLCHAR *)outconstr, (SQLSMALLINT)sizeof(outconstr),
                    (SQLSMALLINT *)&outconlen,SQL_DRIVER_COMPLETE);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in Connect\n");
  stat = SQLAllocStmt(DataBaseConnect,&stmt);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in AllocStmt\n");
  stat = SQLExecDirect(stmt,(SQLCHAR *)sqlstr,strlen(sqlstr));
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in ExecDirect\n");
  /*
  stat = SQLBindCol(stmt,1,SQL_C_LONG,&i,sizeof(i),(SQLINTEGER *)&il);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in BindCol\n");
  */
  stat = SQLBindCol(stmt,2,SQL_C_CHAR,s,sizeof(s),(SQLINTEGER *)&sl);
  if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) printf("Error in BindCol\n");
  for(;;) {
    stat = SQLFetch(stmt);
    if((stat!=SQL_SUCCESS)&&(stat!=SQL_SUCCESS_WITH_INFO)) break;
    s[2] = '\0';
    printf("%s\n",s);
  }
  SQLFreeStmt(stmt,SQL_DROP);
  SQLDisconnect(DataBaseConnect);
  SQLFreeConnect(DataBaseConnect);
  SQLFreeEnv(Environment); 
  return 0;
}

s[2] = '\0';
Har jeg også prøvet med
s[sl] = '\0';
Det dur ikke.
sl = -89125478

Prøv:

stat = SQLBindCol(stmt,1,SQL_C_CHAR,s,sizeof(s),(SQLINTEGER *)&sl);

og

s[sl] = '\0';

andet argument er kolonne nummeret i resultatet hvis jeg husker rigtigt

JEg fandt vidst ud af det tror jeg.
Jeg havde glemt at kalde stat = SQLAllocStmt(DataBaseConnect,&stmt); for hver forespørgsel

Okay, nu ser det ud til at køre...
Endnu et tvivlspg. (Håber ikke jeg presser citronen for meget :) )
Mht. felterne filnavn,ext,size
Lige nu ligger de som du forslog i den samlede tabel.
Men her vil der givet vis også kunne spares en del da ufattelig mange filnavne vil være de samme. Samme filnavn,størrelse og extension.
Ville det være smart at lægge hver ud i sin egen tabel, på samme måde som med stien og så have en reference i samlingstabellen, eller hvad?
Sagen er jo nemlig den at man skal kunne søge på alle attributterne, så hvis man havde dem i hver sin tabel, måske med undtagelse af filstørrelse ville dette godt kunne lade sig gøre. Hvad siger du til denne ide?
Det er jo sådan set bare en viderebygning til det du skrev

Jeg tror at pladsbesparelsen i forhold til omkostningen ved både insert og select
gøt at det ikke kan betale sig.

Og forresten vil jeg gerne lige gi dig point her arne hvis du dropper et svar :)

svar