[algemeen] redundantie voorkomen met invoeren documenten

[Verwijderd]

Hallow,

ik ben bezig met een project waar documenten (via een link en niet fysiek) in een database worden geplaats. Wat je hierbij voor kunt stellen is een applicatie die documenten(.doc, .xls) lokaal oppakt, een aantal eigenschappen uitleest (bvb grootte en bestandsnaam) en ze vervolgens kopiert in een directory en dit pad samen met de andere gegevens opslaat.

Nu vroeg ik me af, hoe is met deze oplossing (of een aanpassing hierop) nu te voorkomen (of grotendeels te voorkomen) dat je bestanden dubbel invoert. Dit betekent namelijk vervuiling.

Hierbij zou je kunnen denken aan het checken van de grootte van de file, maar soms is er net iets gewijzigd en is de grootte anders.

Wat ik me bijvoorbeeld zou kunnen voorstellen is dat er gekeken kan worden naar de grootte (met een speling van een aantal kb) en een hoop overeenkomende woorden in de bestanden. Als de applicatie dan een aantal documenttitels toont en vraagt of dit geen vervangend document is van een van deze documenten kan gekozen worden om hem in te voeren of hem te laten vervangen.

Heeft iemand een beter id, plz shoot!

[Verwijderd]

Hierbij zou je kunnen denken aan het checken van de grootte van de file, maar soms is er net iets gewijzigd en is de grootte anders.

ehm en laten sjekken op datum?

heb je niet freeware tooltjes die je directory in de gaten kan houden op nieuwe files enzo? dan laat je die sjekke en dan pakt jouw applicatie de juiste links op...

[ Voor 33% gewijzigd door Verwijderd op 21-04-2003 20:59 ]

[Verwijderd]

Verwijderd schreef op 21 April 2003 @ 20:56:
[...]


ehm en laten sjekken op datum?

maar als je een wijziging doorvoert, is de datum ook gepast. Of het document is hetzelfde, maar hij's alleen opgeslagen...

[Verwijderd]

een import directory(map voor 16jarigen)

[SWfreak]

Misschien moet je dan denken aan string distances. Als de "afstand" tussen twee documenten te klein is, dan is het hetzelfde document. Maar realiseer je dat hoe goed je mechanisme ook is, je zult altijd documenten die hetzelfde zijn doorlaten en documenten die toch verschillend zijn weigeren.

[Verwijderd]

Wat wil je eigenlijl precies bereiken met deze methode ??
Ik zou zeggen zoek 's op ODMA , is een standaard om documenten op te slaan,
word/excel etc. kunnen hiermee overweg.

[Verwijderd]

Verwijderd schreef op 21 April 2003 @ 21:47:
Wat wil je eigenlijl precies bereiken met deze methode ??
Ik zou zeggen zoek 's op ODMA , is een standaard om documenten op te slaan,
word/excel etc. kunnen hiermee overweg.

Een soort knowledgebase bouwen en dan zorgen dat documenten niet te vaak voorkomen...

[Verwijderd]

Een MD5 hash nemen van iedere file en deze samen met de grootte van de file ergens wegschrijven, deze combinatie lijkt me praktisch volledig uniek per file.

[Knutselsmurf]

Verwijderd schreef op 22 April 2003 @ 01:05:
Een MD5 hash nemen van iedere file en deze samen met de grootte van de file ergens wegschrijven, deze combinatie lijkt me praktisch volledig uniek per file.

Alleen de MD5 is wel genoeg. Vervolgens kun je zelfs de MD5 gebruiken als nieuwe bestandsnaam, zodat je zeker weet dat je niet 2 bestanden met dezelfde naam in je systeem krijgt. Alle andere gegevens, zoals bijvoorbeeld de originele bestandsnaam, kun je kwijt in een database.

[Crazy D]

Knutselsmurf schreef op 22 April 2003 @ 01:50:
Alleen de MD5 is wel genoeg. Vervolgens kun je zelfs de MD5 gebruiken als nieuwe bestandsnaam, zodat je zeker weet dat je niet 2 bestanden met dezelfde naam in je systeem krijgt. Alle andere gegevens, zoals bijvoorbeeld de originele bestandsnaam, kun je kwijt in een database.

Md5 is niet per definitie uniek Maar filesize opslaan is wel handig, als een bestand niet even groot is, kan het sowieso al niet gelijk zijn, hoef je niet eerst de file te md5-en (leuk als ze bestanden van 10Mb uploaden ).

[Verwijderd]

Datum en filesize voldoen inprincipe, ik gebruik het ook in een programma en dat loopt altijd goed.
Je kan natuurlijk wel een geweldig mooi (en waarschijnlijk tijdvretend) algoritme verzinnen, maar waterdicht is het nooit!

[ThaDaNo]

CRC32 hashes, dat is in tegenstelling tot MD5 wel altijd uniek.

[CubicQ]

CRC32 hash is ook niet uniek. Dat is juist de definitie van een hash (en het voordeel ervan).

Maar de kans dat twee verschillende bestanden dezelfde hash opleveren is ontzettend klein, maar kan ook weer niet genegeerd worden (ok, soms wel). Ik zou dus eerst checken op hash (of string distance) en als ze gelijk zijn handmatig de beslissing nemen of een bestand toch moet worden toegevoegd.

[Crazy D]

Hmmm maar robin0223 heeft het er ook over dat als een bestand bijna gelijk is, hij de optie wil bieden een bestaand document te overschrijven. En hoe je dat met een hash kunt checken...

[Verwijderd]

Zelf denk ik dat dat die hash oplossingen allemaal wat 'far fetched' zijn. Het kan namelijk voorkomen, dat een document voor 95% overeenkomt. Dit document wil ik dan eigenlijk niet in de database opnemen(de link dan...). Ik denk zelf dat dit eigenlijk niet af te vangen is op de manier die ik nu bedacht heb.

Ik dacht dat er misschien mensen waren die een super idee hadden waarbij je documenten die grotendeels overeenkomen kan opmerken en dan aan de gebruiker vraagt of die overschreven moet worden...

[ThaDaNo]

CubicQ schreef op 22 april 2003 @ 10:04:
CRC32 hash is ook niet uniek. Dat is juist de definitie van een hash (en het voordeel ervan).

Maar de kans dat twee verschillende bestanden dezelfde hash opleveren is ontzettend klein, maar kan ook weer niet genegeerd worden (ok, soms wel). Ik zou dus eerst checken op hash (of string distance) en als ze gelijk zijn handmatig de beslissing nemen of een bestand toch moet worden toegevoegd.

CRC32 hashes zijn wel uniek. Heb het zelf geprobeerd met een ontzettende lading bestanden en kreeg geen enkele die gelijk was. Bij 1 bit verandering aan het document is het al een andere hash.

Maarre, bekijk het similar_text algoritme van J.J. Oliver eens, of het levehnstein algoritme

[Verwijderd]

DaNo2002 schreef op 22 April 2003 @ 11:20:
[...]

CRC32 hashes zijn wel uniek. Heb het zelf geprobeerd met een ontzettende lading bestanden en kreeg geen enkele die gelijk was. Bij 1 bit verandering aan het document is het al een andere hash.

Maarre, bekijk het similar_text algoritme van J.J. Oliver eens, of het levehnstein algoritme

Ben aan't zoeken, maar bij dat similar_text algoritme kom ik alleen maar php documenten tegen...

[Knutselsmurf]

DaNo2002 schreef op 22 April 2003 @ 11:20:
[...]

CRC32 hashes zijn wel uniek. Heb het zelf geprobeerd met een ontzettende lading bestanden en kreeg geen enkele die gelijk was. Bij 1 bit verandering aan het document is het al een andere hash.

Maarre, bekijk het similar_text algoritme van J.J. Oliver eens, of het levehnstein algoritme

En met een MD5-hash is dat dus nog extremer. Een CRC32 is 32 bit, dus theoretisch heb je een kans van 1/2^32 dat je 2 verschillende bestanden hebt met een zelfde CRC32. Een MD5-hash is 128 bit. Daar is die kans dus afgenomen tot 1/2^128. In mijn ogen is dat uniek genoeg. Volgens mij haal je zelf de tweakers frontpage als je 2 verschillende bestanden met eenzelfde MD5-hash hebt....

[SWfreak]

DaNo2002 schreef op 22 April 2003 @ 11:20:
[...]

CRC32 hashes zijn wel uniek. Heb het zelf geprobeerd met een ontzettende lading bestanden en kreeg geen enkele die gelijk was. Bij 1 bit verandering aan het document is het al een andere hash.

Maarre, bekijk het similar_text algoritme van J.J. Oliver eens, of het levehnstein algoritme

Is een beetje offtopic, maar hashes met een vast uitvoerlengte zijn per definitie niet uniek, ook CRC32. Als je 2^16=65536 bestanden bijelkaar neemt, is de kans erg groot dat je er twee hebt met dezelfde CRC. Neem je er 2^32, dan heb je gegarandeerd een dubbele. Dit omdat CRC32 een 32bits getal is.

Knutselsmurf schreef op 22 april 2003 @ 12:08:
En met een MD5-hash is dat dus nog extremer. Een CRC32 is 32 bit, dus theoretisch heb je een kans van 1/2^32 dat je 2 verschillende bestanden hebt met een zelfde CRC32. Een MD5-hash is 128 bit. Daar is die kans dus afgenomen tot 1/2^128. In mijn ogen is dat uniek genoeg. Volgens mij haal je zelf de tweakers frontpage als je 2 verschillende bestanden met eenzelfde MD5-hash hebt....

Kansen komen eerder in de richting van 1/2^16 en 1/2^64 (vanwege de verjaardagsstelling).

Ontopic: een hash zal de topic-opener niet veel helpen, omdat als ik het goed begrijp het de bedoeling is dat documenten die een klein beetje verschillen gefilterd worden. Een hash kan al bij kleine veranderingen van de input een grote output verandering geven en dat is dus niet handig.
Levenshtein oid lijkt me handiger (is string distance, zoals ik al eerder voorstelde).

[ Voor 22% gewijzigd door SWfreak op 22-04-2003 12:16 ]

[Verwijderd]

SWfreak schreef op 22 April 2003 @ 12:10:
Ontopic: een hash zal de topic-opener niet veel helpen, omdat als ik het goed begrijp het de bedoeling is dat documenten die een klein beetje verschillen gefilterd worden.

Hehe... eindelijk iemand die me begrijpt

Ik vind het heel interessant allemaal, die hash dingen, maar ze zijn niet echt van toepassing. De documenten verschillen namelijk iets.

Een hash kan al bij kleine veranderingen van de input een grote output verandering geven en dat is dus niet handig.
Levenshtein oid lijkt me handiger (is string distance, zoals ik al eerder voorstelde).

Ik ga vrolijk verder met zoeken, tnx voor de input...

[Verwijderd]

Voor de geinteresseerden
http://www.merriampark.com/ld.htm
http://www.powerbasic.com...s/Forum7/HTML/001026.html

Ik zit eraan te denken om bvb een word document te saven als text en deze door de LD heen te halen... Misschien alleen een gedeelte van dit txt document om te zorgen dat het snel genoeg gaat. Dat zal ik proefondervindelijk wel door krijgen.

<edit>
Ook interessant:
http://elj.warwick.ac.uk/jilt/artifint/97_2noor/default.htm
</edit>

[ Voor 13% gewijzigd door Verwijderd op 22-04-2003 13:34 ]