Monsterprojekt?

[Kurt Hansen]

Jeg er retarderet m.h.t. databaser i almindelighed, men jeg har en plan.
Mit problem er at beskrive planen, så databasefolk kan forstå hvad det
er jeg gerne vil lave.

På een eller anden måde skal jeg være ret skarp på at opstille en
kravsspecification, men da jeg kun er nået til det filosofiske stadie,
er det lige tidligt nok.

Det drejer sig om slægtsforskning på nationalt plan. Rigtig meget
kildemateriale er i de senere år blev tilgængeligt på nettet og der
giver jo nogle fantastiske muligheder.

Min overordnede ide er at lave en online database, hvor man f.eks. kan
søge efter f.eks. en Ane (Marie) Pedersdatter, som er født omkring 1834.

Online databasen skal derefter give en overskuelig liste over mulige
kandidater med et output der giver brugeren en rimelig information, så
hun kan vælge.

Det kræver naturligvis en stor indsats med at registrere data fra de
tilgængelige kilder, men det er jo MIT problem.

En af de mange udfordringer er, at personnavne ofte skrives meget
forskelligt. "Ane (Marie)" kan være een af mange forskellige varianter:

Ane Marie
AneMarie
Anne Marie
Ane
- og sikkert flere.

Mandenavnet Lars kan optræde som Lars, Las, Laurids, Lauritz, Laur,
Laurs m.fl.

For brugeren af databasen skal det ikke være for besværligt. At kræve at
man indtaster i en bestemt form, eller at man indsætter diverse * og ?
for at få alle med, er dødsdømt på forhånd. Brugeren sidder og vil gerne
finde en "Ane Pedersdatter" og så bør det være op til databasen at finde
alle relevante varianter.

Overordnet:
Hvilken databasemodel skal jeg vælge? Og hvordan kommer jeg i gang med
eksperimenter? Jeg formoder at det vil være mySQL, men her er jeg helt
blank.

For god ordens skyld: Dette projekt skal munde ud i noget som er "Public
Domain". Jeg kan således ikke tilbyde betaling for hjælp.
--
Venlig hilsen
Kurt Hansen

[Arne Vajhøj]

On 12/25/2017 7:32 AM, Kurt Hansen wrote:
> Det drejer sig om slægtsforskning på nationalt plan. Rigtig meget
> kildemateriale er i de senere år blev tilgængeligt på nettet og der
> giver jo nogle fantastiske muligheder.
>
> Min overordnede ide er at lave en online database, hvor man f.eks. kan
> søge efter f.eks. en Ane (Marie) Pedersdatter, som er født omkring 1834.
>
> Online databasen skal derefter give en overskuelig liste over mulige
> kandidater med et output der giver brugeren en rimelig information, så
> hun kan vælge.

> En af de mange udfordringer er, at personnavne ofte skrives meget
> forskelligt. "Ane (Marie)" kan være een af mange forskellige varianter:
>
> Ane Marie
> AneMarie
> Anne Marie
> Ane
> - og sikkert flere.
>
> Mandenavnet Lars kan optræde som Lars, Las, Laurids, Lauritz, Laur,
> Laurs m.fl.
>
> For brugeren af databasen skal det ikke være for besværligt. At kræve at
> man indtaster i en bestemt form, eller at man indsætter diverse * og ?
> for at få alle med, er dødsdømt på forhånd. Brugeren sidder og vil gerne
> finde en "Ane Pedersdatter" og så bør det være op til databasen at finde
> alle relevante varianter.
>
> Overordnet:
> Hvilken databasemodel skal jeg vælge? Og hvordan kommer jeg i gang med
> eksperimenter? Jeg formoder at det vil være mySQL, men her er jeg helt
> blank.

Jeg tror at du skal bruge noget "fonetisk match".

Lidt forsimplet så har du:
- en funktion f der konverterer navne der skal matche til samme streng
- to kolonner i tabellen: navn og fmnavn hvor fmnavn=f(navn)
- ved søgning så søger du efter f(input) i fmnavn kolonnen

MySQL kommer faktisk med en indbygget SOUNDEX funktion, men mit
gæt er at du skal have lavet en speciel funktion til dit
formål.

Arne

[David Eriksen]

Den 25-12-2017 13:32, Kurt Hansen skrev:
> Jeg er retarderet m.h.t. databaser i almindelighed, men jeg har en plan.
> Mit problem er at beskrive planen, så databasefolk kan forstå hvad det
> er jeg gerne vil lave.
>
> På een eller anden måde skal jeg være ret skarp på at opstille en
> kravsspecification, men da jeg kun er nået til det filosofiske stadie,
> er det lige tidligt nok.
>
> Det drejer sig om slægtsforskning på nationalt plan. Rigtig meget
> kildemateriale er i de senere år blev tilgængeligt på nettet og der
> giver jo nogle fantastiske muligheder.

Tror sgu' alle de databaser der skal bruges til
slægtsforskning er lavet, så det er bare at gå
i gang med at bruge dem


--
David Eriksen

[Kurt Hansen]

Tø-hø, David

Der er ingen grænser for hvor mange databaser der kan laves for
slægtsforskere. Behovet og særlige indgange er på det nærmeste uendelig.

[Kurt Hansen]

Den 25/12/2017 kl. 16.05 skrev Arne Vajhøj:
>
> MySQL kommer faktisk med en indbygget SOUNDEX funktion, men mit
> gæt er at du skal have lavet en speciel funktion til dit
> formål.

Begrebet /fænomenet Soundex husker jeg godt, men har ingen anelse om
hvordan det virker.

Vil Soundex f.eks. finde "Poffuel Stöffuelbech" og omsætte det til "Poul
Støvlbæk"?

[Arne Vajhøj]

mysql> select soundex('Poffuel Stöffuelbech'),soundex('Poul Stovlbæk');
+---------------------------------+--------------------------+
| soundex('Poffuel Stöffuelbech') | soundex('Poul Stovlbæk') |
+---------------------------------+--------------------------+
| P4231412 | P4231412 |
+---------------------------------+--------------------------+
1 row in set (0.02 sec)

Arne

[Kurt Hansen]

Aha! Okay, når man bare ved det, så kan man jo snildt tage højde for det.

Det forekommer at være bra. Det kan jeg godt bruge.

Nu er spørgsmålet bare hvilket database system jeg skal satse på. Mickey
Mouse's blødvarer kender jeg ikke (det hedder vist Access?) og egner sig
vel ikke til offentliggørelse i form af public domain databaser, hvor
folk kan downloade et udtræk?

[David Eriksen]

Den 26-12-2017 17:42, Kurt Hansen skrev:



> Nu er spørgsmålet bare hvilket database system jeg skal satse på. Mickey
> Mouse's blødvarer kender jeg ikke (det hedder vist Access?) og egner sig
> vel ikke til offentliggørelse i form af public domain databaser, hvor
> folk kan downloade et udtræk?

Sig det nu bare som det er: Hvem vil lave det beskidte
arbejde GRATIS for mig

--
David Eriksen

[Kurt Hansen]

Jep, lige nøjagtigt. Jeg har MANGE timers arbejde foran mig og jeg
lægger det ud som publiv domain. Det er HELT frivilligt om nogen vil
hjælpe mig i den gode sags tjeneste.

BTW: Har du nogensinde skrevet et positivt indlæg i denne gruppe?

[David Eriksen]

Den 26-12-2017 20:27, Kurt Hansen skrev:

> Jep, lige nøjagtigt. Jeg har MANGE timers arbejde foran mig og jeg
> lægger det ud som publiv domain. Det er HELT frivilligt om nogen vil
> hjælpe mig i den gode sags tjeneste.
>
> BTW: Har du nogensinde skrevet et positivt indlæg i denne gruppe?

Næ, det har jeg vel ikke, men som i alle de grupper
du frekventerer er du en NASSERØV

--
David Eriksen

[Arne Vajhøj]

On 12/26/2017 11:42 AM, Kurt Hansen wrote:
> Den 26/12/2017 kl. 15.54 skrev Arne Vajhøj:
>> On 12/26/2017 6:00 AM, Kurt Hansen wrote:
>>> Den 25/12/2017 kl. 16.05 skrev Arne Vajhøj:
>>>> MySQL kommer faktisk med en indbygget SOUNDEX funktion, men mit
>>>> gæt er at du skal have lavet en speciel funktion til dit
>>>> formål.
>>>
>>> Begrebet /fænomenet Soundex husker jeg godt, men har ingen anelse om
>>> hvordan det virker.
>>>
>>> Vil Soundex f.eks. finde "Poffuel Stöffuelbech" og omsætte det til
>>> "Poul Støvlbæk"?
>>
>> mysql> select soundex('Poffuel Stöffuelbech'),soundex('Poul Stovlbæk');
>> +---------------------------------+--------------------------+
>> | soundex('Poffuel Stöffuelbech') | soundex('Poul Stovlbæk') |
>> +---------------------------------+--------------------------+
>> | P4231412                        | P4231412                 |
>> +---------------------------------+--------------------------+
>> 1 row in set (0.02 sec)
>
> Aha! Okay, når man bare ved det, så kan man jo snildt tage højde for det.
>
> Det forekommer at være bra. Det kan jeg godt bruge.

Jeg tror stadig at du skal undersøge om soundex er god nok eller
du skal lave din egen funktion.

> Nu er spørgsmålet bare hvilket database system jeg skal satse på. Mickey
> Mouse's blødvarer kender jeg ikke (det hedder vist Access?) og egner sig
> vel ikke til offentliggørelse i form af public domain databaser, hvor
> folk kan downloade et udtræk?

Hvis alle brugere skal køre på deres egen database skal du have en
embedded database.

Hvis du vil have et flerbruger system [med enten mange brugere eller med
internet adgang] så skal du have en database server.

Og du skal naturligvis have en database som understøtter det
programmerings sprog (og platform) du vil bruge til applikationen.

Så start med at bestemme:
- mange enkelbrugere vs flerbruger
- programmerings sprog og platform

Det vil nok indskrænke mulige database systemer en del.

Arne

[Kurt Hansen]

Jeg har været med fra før internet og usenet*. Den gang brugte vi
Fido-net. Disse fora har indtil for nyligt været drevet af hjælpsomhed.

Hvis man tager et gennemsnit over årene er jeg sikker på at jeg har
svaret mindst lige så meget som jeg har spurgt, men nogle emner, som
f.eks. database, kan jeg ikke hjælpe. Om noget har lyst til at hjælpe
mig, er helt frivilligt, men det bliver påskønnet fra min side.

*) Jeg husker dog ikke hvornår usenet blev almindeligt at bruge for lægmand.

Hvis du er forarget over at jeg ikke vil betale for hjælp, er Amino nok
et bedre sted for dig.

[Kurt Hansen]

> On 12/26/2017 11:42 AM, Kurt Hansen wrote:
>
>> Nu er spørgsmålet bare hvilket database system jeg skal satse på.
>> Mickey Mouse's blødvarer kender jeg ikke (det hedder vist Access?) og
>> egner sig vel ikke til offentliggørelse i form af public domain
>> databaser, hvor folk kan downloade et udtræk?

>> Den 26/12/2017 kl. 15.54 skrev Arne Vajhøj:

Den 26/12/2017 kl. 21.51 skrev Arne Vajhøj:

> Hvis alle brugere skal køre på deres egen database skal du have en
> embedded database.
>
> Hvis du vil have et flerbruger system [med enten mange brugere eller med
> internet adgang] så skal du have en database server.

Jeg fik vist ikke udtrykt klart nok, at det er en online database -
altså tilgængelig via internet.

Jeg kan vel købe et godt webhotel til formålet (f.eks. Hosting4Real).
Der er jo alt hvad jeg skal bruge(?).

> Og du skal naturligvis have en database som understøtter det
> programmerings sprog (og platform) du vil bruge til applikationen.

Det mest oplagte må være at køre en mySQL-database og bruge PhP?


Ikke at jeg har forstand på nogen af delene, så jeg kan programmere det
selv, men det bør ikke være vildt indviklet at bruge og det er da også
tænkeligt, at det skal deles op til de forskellige formål.

Eksempel 1:

I genealogien opererer vi med et begreb der hedder "strays" og dette bør
formentlig stå alene som et afgrænset projekt?

Der er et stort behov blandt slægtsforskere for at kunne opspore
personer som havner et helt andet sted i landet og som derfor er
vanskelige eller umulige at finde manuelt.

Jeg har f.eks. her til morgen foretaget en hurtig optælling i
folketællingen 1845 (den første der angiver fødested), som omfatter 1,75
millioner individer. Her finder jeg (med diverse forbehold) omkring 500
morsingboer, som befinder sig de underligste steder i landet. For den
der søger sine aner på Mors er det jo guld værd at få oplyst, at en
given person er havnet på Bornholm (pr. 1845).

Eksempel 2:

Der er anno mange transkriberede kilder til rådighed, samt kilder som er
scannet og ligger tilgængelige online.

Det helt store og forkromede monsterprojekt vil være, at hvis man får et
hit på navn m.m. i databasen, så får man en liste over alle tilgængelige
kilder for den pågældende (med link til hvor man kan se kilden).

Her er udfordringen, så vidt jeg kan se, ikke så meget databasens
indretning og betjeningsmuligheder, men mere et spørgsmål om
"normalisering" af data, så det kan passe ind i databasens felter.

[Arne Vajhøj]

On 12/27/2017 4:41 AM, Kurt Hansen wrote:
>> On 12/26/2017 11:42 AM, Kurt Hansen wrote:
>>> Nu er spørgsmålet bare hvilket database system jeg skal satse på.
>>> Mickey Mouse's blødvarer kender jeg ikke (det hedder vist Access?) og
>>> egner sig vel ikke til offentliggørelse i form af public domain
>>> databaser, hvor folk kan downloade et udtræk?
>>> Den 26/12/2017 kl. 15.54 skrev Arne Vajhøj:
>
> Den 26/12/2017 kl. 21.51 skrev Arne Vajhøj:
>
>> Hvis alle brugere skal køre på deres egen database skal du have en
>> embedded database.
>>
>> Hvis du vil have et flerbruger system [med enten mange brugere eller med
>> internet adgang] så skal du have en database server.
>
> Jeg fik vist ikke udtrykt klart nok, at det er en online database -
> altså tilgængelig via internet.

Saa database server.

> Jeg kan vel købe et godt webhotel til formålet (f.eks. Hosting4Real).
> Der er jo alt hvad jeg skal bruge(?).

Formentligt.

>> Og du skal naturligvis have en database som understøtter det
>> programmerings sprog (og platform) du vil bruge til applikationen.

> Det mest oplagte må være at køre en mySQL-database og bruge PhP?

Det er en meget brugt kombination.

Og det er nemt at finde et web hotel som understøtter den kombination.

> Ikke at jeg har forstand på nogen af delene, så jeg kan programmere det
> selv,

Det er svært at programmeree uden at kunne programmere.

:-)

> Eksempel 1:
>
> I genealogien opererer vi med et begreb der hedder "strays" og dette bør
> formentlig stå alene som et afgrænset projekt?
>
> Der er et stort behov blandt slægtsforskere for at kunne opspore
> personer som havner et helt andet sted i landet og som derfor er
> vanskelige eller umulige at finde manuelt.
>
> Jeg har f.eks. her til morgen foretaget en hurtig optælling i
> folketællingen 1845 (den første der angiver fødested), som omfatter 1,75
> millioner individer. Her finder jeg (med diverse forbehold) omkring 500
> morsingboer, som befinder sig de underligste steder i landet. For den
> der søger sine aner på Mors er det jo guld værd at få oplyst, at en
> given person er havnet på Bornholm (pr. 1845).
>
> Eksempel 2:
>
> Der er anno mange transkriberede kilder til rådighed, samt kilder som er
> scannet og ligger tilgængelige online.
>
> Det helt store og forkromede monsterprojekt vil være, at hvis man får et
> hit på navn m.m. i databasen, så får man en liste over alle tilgængelige
> kilder for den pågældende (med link til hvor man kan se kilden).
>
> Her er udfordringen, så vidt jeg kan se, ikke så meget databasens
> indretning og betjeningsmuligheder, men mere et spørgsmål om
> "normalisering" af data, så det kan passe ind i databasens felter.

Alt det er jo specifik funktionalitet.

Arne

[Kurt Hansen]

Den 27/12/2017 kl. 14.25 skrev Arne Vajhøj:
> On 12/27/2017 4:41 AM, Kurt Hansen wrote:

>> Jeg fik vist ikke udtrykt klart nok, at det er en online database -
>> altså tilgængelig via internet.

> Alt det er jo specifik funktionalitet.

Aha, altså ikke noget med at bruge nogle standardmodeller og moduler som
f.eks. Soundex-søgning?

Javel så. Jamen så har David jo nok desværre ret: At jeg håber at nogen
vil hjælpe mig i gang, uden at jeg skal have tegnebogen op af lommen?

[Arne Vajhøj]

On 12/27/2017 11:20 AM, Kurt Hansen wrote:
> Den 27/12/2017 kl. 14.25 skrev Arne Vajhøj:
>> On 12/27/2017 4:41 AM, Kurt Hansen wrote:
>>> Jeg fik vist ikke udtrykt klart nok, at det er en online database -
>>> altså tilgængelig via internet.
>
>> Alt det er jo specifik funktionalitet.
>
> Aha, altså ikke noget med at bruge nogle standardmodeller og moduler som
> f.eks. Soundex-søgning?

Der kan sikkert godt indgå nogle standard modeller + og jeg er sikker
på at du skal bruge fonetisk match (soundex eller anden).

Min pointe er at dit program er netop det og skal laves som sådant.

Altså:
- definer kravene
- lav database og program design
- implementer
- test

Jeg gætter på at dit projekt vil kræve rigtigt meget arbejde.

Arne

[Kurt Hansen]

Ok, Arne. Tak for dine overordnede betragtninger. Det bringer mig dog
ikke ret meget videre som novice inden for database og PhP.

[Krabsen]

Den 27-12-2017 kl. 18:16 skrev Kurt Hansen:

>> Jeg gætter på at dit projekt vil kræve rigtigt meget arbejde.
>
> Ok, Arne. Tak for dine overordnede betragtninger. Det bringer mig dog
> ikke ret meget videre som novice inden for database og PhP.

Hvis det bringer dig til en erkendelse af, at du er ved at slå et stort
brød op, som du ikke har en ovn der kan bage, bringer det dig et stort
stykke videre. ;-)

Når du nu selv betegner dig som novice inden for database og
programmering er det eneste fornuftige råd man kan give: Glem det.

Vil du gerne lære at programmere f.eks. Php/mySql, så start med et
overskueligt projekt, hvor der er håb om at opleve en succes i ny og næ.


Går du ind på f.eks.
https://www.slaegtogdata.dk/vaerktoejer/programmer/

ser du flere store, web-baserede slægtsforsker-programmer.
Nogle er gratis, nogle koster penge - men fælles for dem alle er at der
ligger programmering bag, der ikke tælles i mandeuger, men mandeår! - og
af rutinerede, professionelle programmører.

[Kurt Hansen]

Den 25/12/2017 kl. 13.32 skrev Kurt Hansen:
> Jeg er retarderet m.h.t. databaser i almindelighed, men jeg har en plan.
> Mit problem er at beskrive planen, så databasefolk kan forstå hvad det
> er jeg gerne vil lave.
>
> På een eller anden måde skal jeg være ret skarp på at opstille en
> kravsspecification, men da jeg kun er nået til det filosofiske stadie,
> er det lige tidligt nok.
>
> Det drejer sig om slægtsforskning på nationalt plan. Rigtig meget
> kildemateriale er i de senere år blev tilgængeligt på nettet og der
> giver jo nogle fantastiske muligheder.
>
> Min overordnede ide er at lave en online database, hvor man f.eks. kan
> søge efter f.eks. en Ane (Marie) Pedersdatter, som er født omkring 1834.
>
> Online databasen skal derefter give en overskuelig liste over mulige
> kandidater med et output der giver brugeren en rimelig information, så
> hun kan vælge.

Måske griber jeg projektet forkert an? Jeg er helt klar over at en
kravsspecifikation er udgangspunktet, men jeg er på famlestadiet
desangående. Jeg søger rådgivning om hvorvidt dette skal have min
højeste prioritet.

At følge princippet om at vi kun har eet efternavn - og hvis vi ser bort
fra begrebet efternavn - så vil min morfar blive registreret i databasen
som "Marinus Balle / Christensen". Jeg går ud fra at vi kan blive enige
om, at når vi skal søge i en online database, så betragter vi "Balle"
som et efternavn? I praksis vil det betyde, at hvis vi søger efter
"Balle" i efternavnefeltet, så finder vi ikke personen, right?

Når vi så har fundet et Balle i databasen, så vil vi sikkert gerne have
udtrukket en alfabetisk liste, som er sorteret på efternavn. Her må jeg
jo så træffe et valg: Skal listen sorteres efter Christensen eller efter
Balle? Jeg kan vel også lade det være op til brugere at vælge hvilken
form hun foretrækker.

Mit spørgsmål/problem er derfor, at jeg allerede nu er nødt til at vide
hvorledes jeg skal organisere mine data - altså hvilke navnefelter jeg
skal have i databasen. Da mit projekt er stort og ambitiøst, er det
vigtigt at gøre det rigtigt fra start, da det vil være en katastrofe at
skulle lave det hele om igen, når jeg kommer så langt, at jeg skal i
gang med selve databasen.

For at kunne imødekomme ønsker om begge dele er jeg nødt til at vide om
jeg alligevel skal operere med "mellemnavne". Når en bruger søger efter
"Balle" kan jeg måske sætte søgningen op til at søge i både "mellemnavn"
og/eller "efternavn"? Jeg ved det ikke og det er derfor jeg spørger.

Det er, for mig, alt for tidligt at diskutere selve implementeringen i
en database. Jeg vil bare gerne vide hvordan jeg skal opdele mine
efternavne.

[Arne Vajhøj]

Givet at:
- man normalt opdeler mellemnavne i fornavne og efternavne
- navne komponenterne har bestemt rækkefølge
så vil jeg finde det mest naturligt med to felter fornavn og
efternavn.

"Anders Børge Christensen Dalby" bliver så til fornavn="Anders Børge"
og efternavn="Christensen Dalby".

Jeg vil formode at sortering på disse er OK, men der skal du nok
konsultere en med domæne ekspertise.

Næste spørgsmål er så søge hastighed.

Du kan jo altid starte med:

... WHERE efternavn LIKE '% Dalby' OR efternavn LIKE 'Dalby %' OR
efternavn LIKE '% Dalby %'

men du skal ikke blive overrasket hvis det går langsomt.

Der er dog flere måde at få det gjort hurtigere.

Du kan bruge databasens FULLTEXT SEARCH muligheder.

Eller du kan selv lave en tabel:

navnekomponent
personid

og bruge den til at slå op i.

Arne

[Kurt Hansen]

Den 09/02/2018 kl. 20.20 skrev Arne Vajhøj:

> On 2/9/2018 12:41 PM, Kurt Hansen wrote:
>> Den 25/12/2017 kl. 13.32 skrev Kurt Hansen:

[klip]

>> Mit spørgsmål/problem er derfor, at jeg allerede nu er nødt til at
>> vide hvorledes jeg skal organisere mine data - altså hvilke
>> navnefelter jeg skal have i databasen. Da mit projekt er stort og
>> ambitiøst, er det vigtigt at gøre det rigtigt fra start, da det vil
>> være en katastrofe at skulle lave det hele om igen, når jeg kommer så
>> langt, at jeg skal i gang med selve databasen.
>>
>> For at kunne imødekomme ønsker om begge dele er jeg nødt til at vide
>> om jeg alligevel skal operere med "mellemnavne". Når en bruger søger
>> efter "Balle" kan jeg måske sætte søgningen op til at søge i både
>> "mellemnavn" og/eller "efternavn"? Jeg ved det ikke og det er derfor
>> jeg spørger.
>>
>> Det er, for mig, alt for tidligt at diskutere selve implementeringen i
>> en database. Jeg vil bare gerne vide hvordan jeg skal opdele mine
>> efternavne.

> Givet at:
> - man normalt opdeler mellemnavne i fornavne og efternavne
> - navne komponenterne har bestemt rækkefølge
> så vil jeg finde det mest naturligt med to felter fornavn og
> efternavn.
>
> "Anders Børge Christensen Dalby" bliver så til fornavn="Anders Børge"
> og efternavn="Christensen Dalby".
>
> Jeg vil formode at sortering på disse er OK, men der skal du nok
> konsultere en med domæne ekspertise.

Mjaaarh, de fleste brugere vil formentlig netop foretrække en sortering
på "Dalby". Det er dét der er problemet.

> Næste spørgsmål er så søge hastighed.
>
> Du kan jo altid starte med:
>
> ... WHERE efternavn LIKE '% Dalby' OR efternavn LIKE 'Dalby %' OR
> efternavn LIKE '% Dalby %'

Ja, eller Dahlby, Dalbye m.fl. stavevarianter i kilderne :-(

> Der er dog flere måde at få det gjort hurtigere.
>
> Du kan bruge databasens FULLTEXT SEARCH muligheder.
>
> Eller du kan selv lave en tabel:
>
> navnekomponent
> personid
>
> og bruge den til at slå op i.

Den finere implementering vender vi tilbage til.

[Krabsen]

Den 10-02-2018 kl. 07:47 skrev Kurt Hansen:
> Den 09/02/2018 kl. 20.20 skrev Arne Vajhøj:
>>
>> "Anders Børge Christensen Dalby" bliver så til fornavn="Anders Børge"
>> og efternavn="Christensen Dalby".
>>
>> Jeg vil formode at sortering på disse er OK, men der skal du nok
>> konsultere en med domæne ekspertise.
>
> Mjaaarh, de fleste brugere vil formentlig netop foretrække en sortering
> på "Dalby". Det er dét der er problemet.

Mjaa - problemet er, at det ved du ikke en dyt om. ;-)
I nogle situationer er det relevant at sortere på Dalby - i andre på
Christensen.
Du ved jo ikke altid hvad Anders Børge kaldte sig i dagligdagen.

[Kurt Hansen]

Den 10/02/2018 kl. 08.26 skrev Krabsen:
> Den 10-02-2018 kl. 07:47 skrev Kurt Hansen:
>> Den 09/02/2018 kl. 20.20 skrev Arne Vajhøj:
>>>
>>> "Anders Børge Christensen Dalby" bliver så til fornavn="Anders Børge"
>>> og efternavn="Christensen Dalby".
>>>
>>> Jeg vil formode at sortering på disse er OK, men der skal du nok
>>> konsultere en med domæne ekspertise.
>>
>> Mjaaarh, de fleste brugere vil formentlig netop foretrække en
>> sortering på "Dalby". Det er dét der er problemet.
>
> Mjaa - problemet er, at det ved du ikke en dyt om. ;-)

Det er nu ikke helt rigtigt. DIS Danmark har 8.000 medlemmer og et
aktivt forum og jeg har jeg berørt emnet på forskellig vis.

Der er naturligvis ikke fuld enighed, men tendensen er altså ret klar.

> I nogle situationer er det relevant at sortere på Dalby - i andre på
> Christensen.
> Du ved jo ikke altid hvad Anders Børge kaldte sig i dagligdagen.

Om han så har kaldt sig Metufisas er ligegyldigt. Det er arkivalier
(kirkebøger, folketællinger m.m.) der ligger til grund for de navne der
optræder i databasen. Hvis ingen af disse indeholder "Metufisas" kommer
det naturligvis ikke med.

Jeg ved på nuværende tidspunkt hvorvidt sådanne sorterede lister
overhovedet kommer på tale. Hvis de gør kan jeg vel give brugeren
mulighed for at vælge med en radio button om de vil have listen sorteret
på den ene eller anden måde. Måske for meget af det gode, men det er vel
teknisk muligt. Så langt er jeg slet ikke kommet endnu.

Det har dog betydning for hvordan jeg strukturerer mine data, som jeg i
øjeblikket bearbejder i Excel og det er derfor jeg spørger: Skal jeg slå
alle efternavne sammen i eet felt, eller skal jeg have tre eller fire
felter til hvert efternavneelement.

[Kurt Hansen]

Den 10/02/2018 kl. 10.29 skrev Kurt Hansen:

> Jeg ved på nuværende tidspunkt hvorvidt sådanne sorterede lister

Her mangler der et IKKE.

> Det har dog betydning for hvordan jeg strukturerer mine data, som jeg i
> øjeblikket bearbejder i Excel og det er derfor jeg spørger: Skal jeg slå
> alle efternavne sammen i eet felt, eller skal jeg have tre eller fire
> felter til hvert efternavneelement.

Præcisering: Der skulle have stået "tre eller fire felter til
efternavneelementerne".

[Arne Vajhøj]

OK.

>> Næste spørgsmål er så søge hastighed.
>>
>> Du kan jo altid starte med:
>>
>> ... WHERE efternavn LIKE '% Dalby' OR efternavn LIKE 'Dalby %' OR
>> efternavn LIKE '% Dalby %'
>
> Ja, eller Dahlby, Dalbye m.fl. stavevarianter i kilderne :-(

Så skal du jo over i fonetisk match. Som vi diskuterede
for nogen tid siden.

Arne

[Kurt Hansen]

Den 25/12/2017 kl. 13.32 skrev Kurt Hansen:
>

> Min overordnede ide er at lave en online database, hvor man f.eks. kan
> søge efter f.eks. en Ane (Marie) Pedersdatter, som er født omkring 1834.
>
> Online databasen skal derefter give en overskuelig liste over mulige
> kandidater med et output der giver brugeren en rimelig information, så
> hun kan vælge.
>
> Det kræver naturligvis en stor indsats med at registrere data fra de
> tilgængelige kilder, men det er jo MIT problem.

Jeg er helt klar over at det er et stort brød jeg har slået op og at
databasekonstruktionen bliver et stort projekt. Det er også derfor jeg
er startet med at organisere mine data og venter med det mere tekniske.

Det der er vigtigt lige nu er hvordan jeg skal registrere efternavn(e),
som der kan være 3-4 elementer af, f.eks. "Schade Ottesen Birckwaldt".

Mine kilder indeholder det komplette navn, f.eks. "Peter Andreas Schade
Ottesen Birckwaldt".

Det største problem er faktisk, at Excel jo ikke kan vide om Schade er
et fornavn eller efternavn, så jeg har meget svært ved at regne ud
hvordan jeg kan automatisere processen. I praksis kan jeg blive nødt til
at afgøre det manuelt i hvert enkelt tilfælde, men da jeg opererer med
flere hundrede tusinde poster, så er det jo ikke realistisk.

Personer med to navneelementer er jo nemme og andre småtricks, som
f.eks. at filtrere på elementer der ender på -sen, kan gøre en del af de
grove arbejde, men alligevel er det tidkrævende.

Jeg har lavet folketællingen 1845 på denne måde og det tog en hel dag.
Jeg har, for alle tilfældes skyld, lagret både et felt med alle
efternavne, samt felter med hver et efternavneelement, Så er jeg vist
dækket ind?

Jeg krydsposter dette indlæg til "dk.edb.regneark".

[Jan Kronsell]

>
>
>Jeg er helt klar over at det er et stort brød jeg har slået op og at
>databasekonstruktionen bliver et stort projekt. Det er også derfor jeg er
>startet med at organisere mine data og venter med det mere tekniske.
>
>Det der er vigtigt lige nu er hvordan jeg skal registrere efternavn(e), som
>der kan være 3-4 elementer af, f.eks. "Schade Ottesen Birckwaldt".
>
>Mine kilder indeholder det komplette navn, f.eks. "Peter Andreas Schade
>Ottesen Birckwaldt".
>
>Det største problem er faktisk, at Excel jo ikke kan vide om Schade er et
>fornavn eller efternavn, så jeg har meget svært ved at regne ud hvordan jeg
>kan automatisere processen. I praksis kan jeg blive nødt til at afgøre det
>manuelt i hvert enkelt tilfælde, men da jeg opererer med flere hundrede
>tusinde poster, så er det jo ikke realistisk.
>

Som jeg tidligere har skrevet, er det nærmest en umulighed at automatisere
processer, hvor der ikke er systematik i de data, der skal behandles. Og det
er jo præcis din udfordring her. Nogle mellemnavn er fornavn, mens andre er
efternavne, og det kan intet program formodentlig afgøre - og så er du
tilbage ved den manuelle behandling. Også manuelt kan det af og til være
vanskeligt, da nogle navne jo kan optræde som begge dele - og hvad er det så
i det givne tilfælde?

>
>med to navneelementer er jo nemme og andre småtricks, som f.eks. at
>filtrere på elementer der ender på -sen, kan gøre en del af de grove
>arbejde, men alligevel er det tidkrævende.
>
>Jeg har lavet folketællingen 1845 på denne måde og det tog en hel dag. Jeg
>har, for alle tilfældes skyld, lagret både et felt med alle efternavne,
>samt felter med hver et efternavneelement, Så er jeg vist dækket ind?
>

Dette kan være vejen frem, men det betyder at du får forskelligt antal
felter i de forskellige poster, og det er databasedesignmæssigt, absolut i
modstrid med "reglerne". Her skal alle poster være af samme længde. Hvis du
laver søgning med jokertegn i det samlede felt, behøver du vel slet ikke de
andre felter? Altså hvis jeg kan søge efter Schrøder og så finde 'de Fine
Schrøder Christensen', så behøver jeg ikke et felt til hvert efternavn. Den
samme problemstilling må vel også gælde for fornavne. Albert Louis Nielsen,
kan have været kendt som Louis, og nogen ved måske slet ikke at han hed
Albert. Så skal en søgning på Louis alene, jo også finde ham.

Så måske er det mest oplagte at lave et felt til hele navnet - i hvert fald
udadtil.

Jan

[Arne Vajhøj]

On 2/11/2018 1:14 AM, Kurt Hansen wrote:
> Den 25/12/2017 kl. 13.32 skrev Kurt Hansen:
>>
>> Min overordnede ide er at lave en online database, hvor man f.eks. kan
>> søge efter f.eks. en Ane (Marie) Pedersdatter, som er født omkring 1834.
>>
>> Online databasen skal derefter give en overskuelig liste over mulige
>> kandidater med et output der giver brugeren en rimelig information, så
>> hun kan vælge.
>>
>> Det kræver naturligvis en stor indsats med at registrere data fra de
>> tilgængelige kilder, men det er jo MIT problem.
>
> Jeg er helt klar over at det er et stort brød jeg har slået op og at
> databasekonstruktionen bliver et stort projekt. Det er også derfor jeg
> er startet med at organisere mine data og venter med det mere tekniske.
>
> Det der er vigtigt lige nu er hvordan jeg skal registrere efternavn(e),
> som der kan være 3-4 elementer af, f.eks. "Schade Ottesen Birckwaldt".
>
> Mine kilder indeholder det komplette navn, f.eks. "Peter Andreas Schade
> Ottesen Birckwaldt".
>
> Det største problem er faktisk, at Excel jo ikke kan vide om Schade er
> et fornavn eller efternavn, så jeg har meget svært ved at regne ud
> hvordan jeg kan automatisere processen. I praksis kan jeg blive nødt til
> at afgøre det manuelt i hvert enkelt tilfælde, men da jeg opererer med
> flere hundrede tusinde poster, så er det jo ikke realistisk.
>
> Personer med to navneelementer er jo nemme og andre småtricks, som
> f.eks. at filtrere på elementer der ender på -sen, kan gøre en del af de
> grove arbejde, men alligevel er det tidkrævende.

Hvad med at hente lister med kendte fornavne og kendte efternavne
og så lade import program udefra disse vælge:
* klart fornavn
* klart efternavn
* tvivl => manuelt valg

Hvis tvivls andelen kommer ned på 0.1-1%, så må manuelt
virke.

Arne

[Krabsen]

Den 11-02-2018 kl. 17:17 skrev Arne Vajhøj:
> On 2/11/2018 1:14 AM, Kurt Hansen wrote:
>> Den 25/12/2017 kl. 13.32 skrev Kurt Hansen:
>>>
>>> Min overordnede ide er at lave en online database, hvor man f.eks.
>>> kan søge efter f.eks. en Ane (Marie) Pedersdatter, som er født
>>> omkring 1834.
>>>
>>> Online databasen skal derefter give en overskuelig liste over mulige
>>> kandidater med et output der giver brugeren en rimelig information,
>>> så hun kan vælge.
>>>
>>> Det kræver naturligvis en stor indsats med at registrere data fra de
>>> tilgængelige kilder, men det er jo MIT problem.

> Hvad med at hente lister med kendte fornavne og kendte efternavne
> og så lade import program udefra disse vælge:
> * klart fornavn
> * klart efternavn
> * tvivl => manuelt valg

Som f.eks. "Hans Peter Åse" :-)

[Arne Vajhøj]

Hmmm. Der skal nok nogle flere regler på. Første altid fornavn,
sidste altid efternavn, og kønsspecifikke fornavns lister.

Arne

[Jan Kronsell]

>
>Hvad med at hente lister med kendte fornavne og kendte efternavne
>og så lade import program udefra disse vælge:
>* klart fornavn
>* klart efternavn
>* tvivl => manuelt valg
>
>Hvis tvivls andelen kommer ned på 0.1-1%, så må manuelt
>virke.

Jeg tror ikke at jeg har hørt om sådanne lister, der rummer alle fornavne og
efternavne. Husk der er tale om slægtforskning, så det kan gå langt tilbage
i tiden, da navnene, der var i brug var anderledes end i dag. Og ås er der
alle de tilfælde, hvor et navn kan fungere både som fornavn og efternavn.
Her vil man måske kunne komme i tvivl selv ved manuel behandling.

Jan

[Kurt Hansen]

Den 11/02/2018 kl. 12.49 skrev Jan Kronsell:
>>
>> Jeg har lavet folketællingen 1845 på denne måde og det tog en hel dag.
>> Jeg har, for alle tilfældes skyld, lagret både et felt med alle
>> efternavne, samt felter med hver et efternavneelement, Så er jeg vist
>> dækket ind?

> Dette kan være vejen frem, men det betyder at du får forskelligt antal
> felter i de forskellige poster, og det er databasedesignmæssigt, absolut
> i modstrid med "reglerne". Her skal alle poster være af samme længde.

Et tomt felt er altså i strid med reglerne, forstår jeg.

> Hvis du laver søgning med jokertegn i det samlede felt, behøver du vel
> slet ikke de andre felter? Altså hvis jeg kan søge efter Schrøder og så
> finde 'de Fine Schrøder Christensen', så behøver jeg ikke et felt til
> hvert efternavn. Den samme problemstilling må vel også gælde for
> fornavne. Albert Louis Nielsen, kan have været kendt som Louis, og nogen
> ved måske slet ikke at han hed Albert. Så skal en søgning på Louis
> alene, jo også finde ham.
>
> Så måske er det mest oplagte at lave et felt til hele navnet - i hvert
> fald udadtil.

Til søgning ja, men igen: Hvis jeg vil udtrække en liste som er sorteret
på efternavn, så har vi balladen, som jeg beskrev længere oppe i tråden.

[Kurt Hansen]

Ideen er oplagt. Problemet er imidlertid, at kildernes stavemåder for
selv almindelige navne kan være ret forskellig.

Okay, sådan en kunne jeg jo selv lave ud fra de registrerede data, men
det vil jo igen kræve, at jeg får adskilt for- og efternavne.

[David Eriksen]

Den 12-02-2018 09:35, Kurt Hansen skrev:

Måske i skulle undgå krydspostning i mellem denne
gruppe og regneark...


--
David Eriksen

---
Denne mail er kontrolleret for vira af AVG.
http://www.avg.com

[Krabsen]

Og her er du jo ved kardinalpunktet - det kan simpelthen ikke lade sig
gøre at lave altdækkende, maskinelt håndterbare regler for navne -
ellers var det nok gjort :-)

Kønsspecifikke fornavne? Som f.eks. Gert/Gerd - Kim - Jan ?

[Jan Kronsell]

>
>Et tomt felt er altså i strid med reglerne, forstår jeg.
>

Et enkelt tomt felt er ok. Men hvis du laver fx 10 felter, og der i de
fleste poster kun er data i fx 3 af disse, er det ikke godt.

>
>Til søgning ja, men igen: Hvis jeg vil udtrække en liste som er sorteret på
>efternavn, så har vi balladen, som jeg beskrev længere oppe i tråden.

Jeps. Men så ville jeg lave et felt til det sidste navn, og så et felt til
resten af navnet.

Jan

[Arne Vajhøj]

Det aspekt skal stadig løses med en soundex lignende løsning.
Uanset hvordan navnene håndteres.

Arne