[VB.Net] n00bvraag structures/arrays in mdb

[Sorcerer8472]

oi medetweakers

Ik heb een probleem... Ik ben n00b in databaseapplicaties maar wilde in VB.Net toch een applicatie schrijven die gigantisch veel gegevens moet opslaan en laden...

Het gaat daarbij om structures waarin ook arrays zitten (of die ook meteen arrays zijn)... Die moeten zo efficient en overzichtelijk mogelijk opgeslagen worden in een mdb-file (liefst ook raw accessbaar zonder dat je cryptograaf hoeft te zijn om het te kunnen lezen), en daar later uit geladen worden en weer omgezet worden naar variabelen.

Kent iemand hier een goeie tutorial voor? Via google en visualbasic.pagina.nl vind ik namelijk niks nuttigs... en de helpfile laat me ook alleen met vraagtekens achter

Bij voorbaat dank
- Sorce

[gorgi_19]

Kan je misschien iets duidelijker zijn, ik weet nu niet in welk gedeelte je probleem zit.
Als het is met het opslaan van gegevens, dan zit je op de verkeerde sites te kijken; je probleem is dan hoe je een relationele database inricht (en dit gedeelte heeft nog niets met VB.net te maken)

Het andere gedeelte, hoe om te gaan met al deze gegevensstromen. Ik weet niet hoe je je data wilt opslaan en wat voor data het is, maar je kan sowieso je eigen objecten aanmaken en deze vullen. (VB.net is 'volledig' OO)

Tutorials zijn wel te vinden op www.4guysfromrolla.com / www.aspalliance.com; eventueel kan je ook nog wel een aantal discussies zien op www.asp.net, tezamen met tutorials.

[Sorcerer8472]

Mijn probleem gaat niet over ASP... Het gaat over het efficient opslaan van variabelen in de vorm van structures en arrays (daarin) in een Jet4-database (.mdb).
Het sowieso opslaan van dingen in SQL-vorm is geen probleem... Het implementeren van SQL in VB.Net op een efficiënte manier wel...

Thanx voor de reactie though

[Verwijderd]

Ik begrijp je vraag ook niet zo goed. Heb je al een database? zo ja is die al dmv ODBC berijkbaar? zo ja heb je in VB al een DataEnvironment met SQL statements?

edit:


Sorry had je reply nog niet gelezen. Ik zit dus ook op het verkeerd spoor

[Verwijderd]

Waarom structures en arrays, als je het vervolgens in een access database wilt opslaan?
Hiervoor gebruik je ADO.NET, die levert deze objecten in de vorm van datasets... klaar!

Zoek dus even op ADO.NET en dataset

[Lister]

Wat ik altijd doe is per type structure 1 tabel aanmaken, en als je "hoofd" en "sub" structures hebt dan neem je in de "sub" structure tabel een veld op dat verwijst naar het sleutelveld van de "hoofd" structure.

Het opslaan en uitlezen is dan relatief eenvoudig omdat je per object 1 record hebt waarin eventueel een verwijzing zit naar een bovenliggend object.

Komt dit een beetje duidelijk over?

[Sorcerer8472]

Verwijderd schreef op 29 september 2002 @ 22:13:
Waarom structures en arrays, als je het vervolgens in een access database wilt opslaan?
Hiervoor gebruik je ADO.NET, die levert deze objecten in de vorm van datasets... klaar!

Zoek dus even op ADO.NET en dataset

Omdat mijn programma zodanig intensief omgaat met die data dat het bij een gebruik van een externe database veel te langzaam zou werken (hij spit de hele database, die een paar MB groot zal zijn tienduizenden keren door - administratief programma voor bedrijven)...

[Gé Brander]

Sorcerer8472 schreef op 29 september 2002 @ 22:25:
[...]


Omdat mijn programma zodanig intensief omgaat met die data dat het bij een gebruik van een externe database veel te langzaam zou werken (hij spit de hele database, die een paar MB groot zal zijn tienduizenden keren door - administratief programma voor bedrijven)...

Daarom is een database juist wel geschikt. dan kan je met stored procedures die acties op de server uit laten voeren en alleen het resultaat naar de client laten gaan.

[Sorcerer8472]

c70070540 schreef op 29 september 2002 @ 22:28:
[...]


Daarom is een database juist wel geschikt. dan kan je met stored procedures die acties op de server uit laten voeren en alleen het resultaat naar de client laten gaan.

Dat kan niet... Er is geen server, het programma moet het zelf doen op de computer van een derde, anders zou ik wel een SQL-server gebruiken hoor

[Sorcerer8472]

ADO.Net zal ik even nazoeken

[Verwijderd]

Er is geen server, het programma moet het zelf doen op de computer van een derde, anders zou ik wel een SQL-server gebruiken hoor

Waarom dan niet upscalen naar msde? administratief pakket lijkt me dat het voornamelijk stabiel en betrouwbaar moet zijn en laten dat nu net niet de 2 steekwoorden zijn waar ik aan denk als je mdb roept ("ja de mdb is weer corrupt , moet je 'm even proberen in te laden met access en repair/compress doen of anders even 'n backupje van gister terug zetten"...ehhh right...)

[Sorcerer8472]

Niet op die manier administratief... Hij moet een gigantisch werkrooster samenstellen, met tienduizenden variabelen...
Die variabelen wilde ik in het programma verwerken en gebruiken en dan op commando opslaanbaar maken.

Met andere woorden:
Het programma werkt met variabelen (structures, arrays) en moet vervolgens DIE informatie kwijt in een database (moet ook weer uit te lezen zijn door hetzelfde programma), en dan kan ik net zo goed mdb gebruiken.
Tussentijds wordt er NIET in een database gewerkt.

[Sorcerer8472]

Overigens, gebruikt VB.Net niet standaard ADO.Net voor alle database-access?

[Verwijderd]

Kortom je wilt niets meer / minder dan gewoon 'n save/load functie? kan je 't niet gewoon in 'n text bestand rammen?

[Sorcerer8472]

Verwijderd schreef op 30 september 2002 @ 00:21:
Kortom je wilt niets meer / minder dan gewoon 'n save/load functie? kan je 't niet gewoon in 'n text bestand rammen?

Liever niet... In een Access-bestand kan de gebruiker zelf makkelijker dingen aanpassen en eventueel delen van gegevens al uit andere databases halen.

Voor de rest is het in principe inderdaad alleen een save/loadfunctie... Tenminste ik neem aan dat VB.Net met behoorlijk veel vars tegelijk kan werken

[Sorcerer8472]

Maargoed, misschien had ik meteen save/loadfunctie moeten zeggen

Ik zit nog steeds met hetzelfde probleem: (sub)structures waarin ook arrays zitten (soms zelfs een array binnen een array ) opslaan naar een databasebestand...

[Sorcerer8472]

Heb er nog eens over nagedacht: Zou het een goed idee zijn een class te maken waarmee ik makkelijk die data kan wegschrijven zodat ik niet telkens dezelfde commando's hoef uit te voeren? Is dat een haalbaar idee?

Kvraag me nog steeds af hoe ik die arrays moet doen trouwens...
Stel je es voor je hebt blaat(0) tot en met 8000 ofzo en je wilt dat wegschrijven...

_{Ja, triest, ik weet het, 3e post van mezelf onder elkaar, maar er viel me weer eens iets in en een edit is dan ook zo dom}

[OMX2000]

Sorcerer8472 schreef op 30 september 2002 @ 08:48:
Heb er nog eens over nagedacht: Zou het een goed idee zijn een class te maken waarmee ik makkelijk die data kan wegschrijven zodat ik niet telkens dezelfde commando's hoef uit te voeren? Is dat een haalbaar idee?

Kvraag me nog steeds af hoe ik die arrays moet doen trouwens...
Stel je es voor je hebt blaat(0) tot en met 8000 ofzo en je wilt dat wegschrijven...

_{Ja, triest, ik weet het, 3e post van mezelf onder elkaar, maar er viel me weer eens iets in en een edit is dan ook zo dom}

Zijn die "structures/arrays" van zo'n aard dat je ze meerdere keren opslaat. Dus voor object A, heb je 30 "properties" in die array. En in object B 40? Want dan kun je met een soort van meta-database werken. Waarin in 1 tabel staat welke properties bij een bepaald object horen. En in de andere tabel de data zelf per propertie... Dit heeft alleen zin als je dus meerdere keren gebruik maakt van dezelfde set properties, anders is dit gigantisch inefficient...

[Creepy]

Ik heb het idee dat je beter ff kan opschrijven wat je allemaal wilt gaan opslaan, en dan "ouderwets" gaan normaliseren.
Over het algemeen ontwerp je eerst je DB VOORDAT je je programma gaat schrijven.

Mocht je niet weten wat normaliseren is, zoek daar maar een tutorial voor op

[OMX2000]

Creepy schreef op 30 september 2002 @ 09:10:
Ik heb het idee dat je beter ff kan opschrijven wat je allemaal wilt gaan opslaan, en dan "ouderwets" gaan normaliseren.
Over het algemeen ontwerp je eerst je DB VOORDAT je je programma gaat schrijven.

Mocht je niet weten wat normaliseren is, zoek daar maar een tutorial voor op

Leuk hoor... maar databases zijn niet echt gemaakt om heel erg "grillige" data op te slaan. Daar is xml heel erg goed geschikt voor. Je kunt in databases wel anders modelleren om toch veranderlijke datastructuren op te slaan, maar daar kom je niet zomaar met normaliseren. Je zou zelfs heel simpel een memoveld kunnen gebruiken om er xml in op te slaan voor de properties die zo veranderlijk zijn.

[Sorcerer8472]

OMX2000 schreef op 30 september 2002 @ 09:06:
[...]


Zijn die "structures/arrays" van zo'n aard dat je ze meerdere keren opslaat. Dus voor object A, heb je 30 "properties" in die array. En in object B 40? Want dan kun je met een soort van meta-database werken. Waarin in 1 tabel staat welke properties bij een bepaald object horen. En in de andere tabel de data zelf per propertie... Dit heeft alleen zin als je dus meerdere keren gebruik maakt van dezelfde set properties, anders is dit gigantisch inefficient...

Even een voorbeeld van een paar structuren:

Woei(0).Blaat.Koe
Woei(0).Blaat.Anderdier
Woei(0).Kraai.Kip
etc.

Koe=boolean
Anderdier=string
Kip=integer

Uiteraard verschilt 0 van 1, 2, 3 etc, maar Koe is en blijft overal een boolean uiteraard
Kraai is dan een structure voor weer andere variabelen...

Ik weet niet helemaal zeker of je dat bedoelt though. Iets duidelijker zo?

[gorgi_19]

Sorcerer8472 schreef op 30 september 2002 @ 09:31:
[...]


Even een voorbeeld van een paar structuren:

Woei(0).Blaat.Koe
Woei(0).Blaat.Anderdier
Woei(0).Kraai.Kip
etc.

Koe=boolean
Anderdier=string
Kip=integer

Uiteraard verschilt 0 van 1, 2, 3 etc, maar Koe is en blijft overal een boolean uiteraard
Kraai is dan een structure voor weer andere variabelen...

Ik weet niet helemaal zeker of je dat bedoelt though. Iets duidelijker zo?

Een vraagje, maar werkt dit dan niet? Op deze manier hoef je toch niet heel ingewikkeld te doen? (En ook als iemand ziet dat er geen hout van klopt, dan hoor ik dit graag..

code:

...
    Public Class objBlaat
        Private _koe As Boolean
        Private _anderdier As String
        Public Property koe() As Boolean
            Get
                Return _koe

            End Get
            Set(ByVal Value As Boolean)
                _koe = Value
            End Set
        End Property

        Public Property AnderDier() As String
            Get
                Return _anderdier
            End Get
            Set(ByVal Value As String)
                _anderdier = Value
            End Set
        End Property
    End Class

    Public Class objKraai
        Private _kip As Integer

        Public Property Kip() As Integer
            Get
                Return _kip
            End Get
            Set(ByVal Value As Integer)
                _kip = Value
            End Set
        End Property
    End Class

    Public Class Woei
        Private _blaat As objBlaat
        Private _kraai As objKraai

        Public Sub New()
            _blaat = New objBlaat()
            _kraai = New objKraai()
        End Sub

        Public Property Blaat() As objBlaat
            Get
                Return _blaat
            End Get
            Set(ByVal Value As objBlaat)
                _blaat = Value
            End Set
        End Property

        Public Property Kraai() As objKraai
            Get
                Return _kraai
            End Get
            Set(ByVal Value As objKraai)
                _kraai = Value
            End Set
        End Property
    End class

[Verwijderd]

Je draait vb.net dus je kan toch gewoon je objecten zich zelf laten seriealizen naar 'n xmlwriter oid? teminste wel es met de samples zitten spelen en daar leek het eazy as 123.

[Creepy]

OMX2000 schreef op 30 september 2002 @ 09:22:
[...]


Leuk hoor... maar databases zijn niet echt gemaakt om heel erg "grillige" data op te slaan. Daar is xml heel erg goed geschikt voor. Je kunt in databases wel anders modelleren om toch veranderlijke datastructuren op te slaan, maar daar kom je niet zomaar met normaliseren. Je zou zelfs heel simpel een memoveld kunnen gebruiken om er xml in op te slaan voor de properties die zo veranderlijk zijn.

Data blijft data.. en dat is te normaliseren. Dus ook goed op te slaan in een DB. De representatie van je data is misschien wat anders dan dat je dat gebruikt in je programma zelf, maar dat maakt nou niet veel uit.

Databases normaliseer je, anders gebruik je geen database.

Die dieren die hier genoemd worden zijn goed op te slaan in een DB (en ook te normaliseren).

"Grillige" data maak je juist minder "grillig" door te normaliseren. Daar is normaliseren juist voor bedoeld!

XML om data in op te slaan? Kijk eerst eens naar databases, zeker als het gaat om veel data. Toen XML nog geen hype was werd er ook eerst gekeken naar een DB formaat om de zooi in op te slaan, of desnoods een eigen bestand formaat. Nu XML een hype is lijkt het wel ofdat iedereen eerst gaat proberen z'n app met XML te laten werken.. affijn.

Tuurlijk kan je ook zonder te normaliseren data in je DB opslaan maar dan gebrui je je DB puur en alleen als een vergaar bak, en kan je net zo goed tekstbestanden gaan gebruiken ofzo.

[OMX2000]

Creepy schreef op 30 september 2002 @ 09:54:
[...]

Data blijft data.. en dat is te normaliseren. Dus ook goed op te slaan in een DB. De representatie van je data is misschien wat anders dan dat je dat gebruikt in je programma zelf, maar dat maakt nou niet veel uit.

Databases normaliseer je, anders gebruik je geen database.

Die dieren die hier genoemd worden zijn goed op te slaan in een DB (en ook te normaliseren).

"Grillige" data maak je juist minder "grillig" door te normaliseren. Daar is normaliseren juist voor bedoeld!

XML om data in op te slaan? Kijk eerst eens naar databases, zeker als het gaat om veel data. Toen XML nog geen hype was werd er ook eerst gekeken naar een DB formaat om de zooi in op te slaan, of desnoods een eigen bestand formaat. Nu XML een hype is lijkt het wel ofdat iedereen eerst gaat proberen z'n app met XML te laten werken.. affijn.

Tuurlijk kan je ook zonder te normaliseren data in je DB opslaan maar dan gebrui je je DB puur en alleen als een vergaar bak, en kan je net zo goed tekstbestanden gaan gebruiken ofzo.

Een paar posts hierboven heb ik dat ook al aangegeven... Je kunt ook een meta-database model gebruiken. En die kan perfect genormaliseerd worden, maar dat is dus niet fijn in gebruik. Als je een meta-database model gebruikt kun je niet zomaar gebruik maken van standaard constraints. Omdat je nu relaties moet leggen tussen entiteiten in een tabel, in plaats van relaties tussen tabellen. Het kan natuurlijk wel, want de definities van tabellen gebeurd in SQL Server bijv ook in meta-tabellen. Maar dat bouw je niet zomaar even...

[gorgi_19]

Creepy schreef op 30 september 2002 @ 09:54:
[...]

Data blijft data.. en dat is te normaliseren. Dus ook goed op te slaan in een DB. De representatie van je data is misschien wat anders dan dat je dat gebruikt in je programma zelf, maar dat maakt nou niet veel uit.

Databases normaliseer je, anders gebruik je geen database.

Die dieren die hier genoemd worden zijn goed op te slaan in een DB (en ook te normaliseren).

"Grillige" data maak je juist minder "grillig" door te normaliseren. Daar is normaliseren juist voor bedoeld!

XML om data in op te slaan? Kijk eerst eens naar databases, zeker als het gaat om veel data. Toen XML nog geen hype was werd er ook eerst gekeken naar een DB formaat om de zooi in op te slaan, of desnoods een eigen bestand formaat. Nu XML een hype is lijkt het wel ofdat iedereen eerst gaat proberen z'n app met XML te laten werken.. affijn.

Tuurlijk kan je ook zonder te normaliseren data in je DB opslaan maar dan gebrui je je DB puur en alleen als een vergaar bak, en kan je net zo goed tekstbestanden gaan gebruiken ofzo.

XML beschouw ik als een handig formaat om gegevens uit te wisselen; zeker als ook externe applicaties gebruik moeten maken van de gegevens.

Ik ben de (directe) relatie vooralsnog met VB.Net (en dan de business logic) en de gegevensbenadering vooralsnog even kwijt. Wat je kan doen is de database en de business logic scheiden, is er ook geen discussie meer over "welke database" en "wel of geen XML-based"-database of "wel of geen XML als opslagmedium", het is dan aan de klant om dit te beslissen. Wil hij een andere db, dan kan je een andere databaselaag maken en deze naast de andere neerzetten; voor de werking van de rest heeft dit geen invloed.

Als je gaat werken met enorme aantallen gegevens, vraag ik me af of het niet verstandiger is om tussentijds alles op te slaan, zeker de gegevens die je niet meer gaat gebruiken of die al helemaal verwerkt zijn. Je gaat Access gebruiken, dus zulke enorme aantallen gegevens zal je niet hebben.

En tsja, je zult toch waarschijnlijk niet alles met 1 query kunnen wegschrijven, maar hier meerdere voor nodig hebben, wat op zich niet erg is.

[Creepy]

Als ik het zo lees heeft de topicstarter een aantal vaste objecten (structures). Die kan je vrij makkelijk opslaan in een DB. Daar heb je geen meta data voor nodig.

Op het moment dat je structures ook nog eens van inhoud blijven veranderen is jou (=OMX2000) oplossing inderdaad een stuk handiger (en inderdaad XML voor data en metadata opslag een stuk beter IMHO).

Als de structures zelf een niet veranderlijke structuur hebben zou ik ze in een DB opslaan.

Maar als ik het zo bekijk dan was het waarschijnlijk beter geweest dat de topic starter eerst was gaan kijken hoe precies de data te representeren, a.d.v. een formaat te kiezen op alles in op te slaan. I.p.v. eerst een structuur te maken, en dan nog eens te gaan kijken hoe dit op te slaan.

[Sorcerer8472]

Nogmaals, ik heb totaal geen VB-database-ervaring... maar als iemand me een richting op kan duwen ga ik in die richting een tutorial doen of de boel lezen uit een boek...

Ik heb vaste structures (met arrays daarin)... De namen van variabelen in die structure en van de structure zelf blijven altijd gelijk (duh ), maar de inhoud zou wel kunnen veranderen.
Dit dacht ik op te kunnen lossen door bij te houden wat er veranderd is sinds de laatste save, en alleen dat opnieuw weg te schrijven in het databasebestand.

[Verwijderd]

Je kunt in dit geval prima gebruik maken van de serialisatie mogelijkheden van .NET. Gewoon je gehele objectmodel serialiseren naar een filestream.

[Creepy]

Verwijderd schreef op 30 september 2002 @ 13:13:
Je kunt in dit geval prima gebruik maken van de serialisatie mogelijkheden van .NET. Gewoon je gehele objectmodel serialiseren naar een filestream.

Zoals yarvieh al aangaf dus

[Sorcerer8472]

Klinkt lastig

Bovendien heb ik een zware voorkeur naar een Access-document, omdat het dan met MS Access in te lezen is...

Erg intensief wordt er niet gebruik gemaakt van de database... Laden en wegschrijven... Meer niet.