Print Page - Static vs Dynamic Databases

Active Forums => QB64 Discussion => Topic started by: SMcNeill on October 04, 2018, 01:26:37 pm

Title: Static vs Dynamic Databases
Post by: SMcNeill on October 04, 2018, 01:26:37 pm

I was working on a little pet project for a friend this morning, and we got to discussing various types of databases. Apparently, the definition of "database" has changed from what I used to know it as, and so has what folks call "dynamic databases" and "static databases".

Apparently, the modern definition of "static" or "dynamic" is simply determined by how we reserve memory for our database when we initially create it... https://www.ayomaonline.com/academic/static-vs-dynamic-data-structures/

Quote

Static Data Structures

As same as the word static suggests, static data structures are designed to store static “set of data”. However, static “set of data”, doesn’t mean that we can not change the assigned values of elements. It is the memory size allocated to “data”, which is static.

Quote

Dynamic Data Structures

Dynamic data structures are designed to facilitate change of data structures in the runtime. It is possible to change the assigned values of elements, as it was with static structures. Also, in dynamic structures the initially allocated memory size is not a problem. It is possible to add new elements, remove existing elements or do any kind of operation on data set without considering about the memory space allocated initially.

*****************
*****************

Since when did the definition become that?? Apparently, if I DIM array(whatever), it's a STATIC database, but REDIM array(whatever) is DYNAMIC??

That's not how I've always used the words....

For me, a static database is one where the STRUCTURE remains static and unchanging. We might add or remove records -- thus changing the amount of memory the database consumes -- but the elements/structure of the data doesn't change itself.

Name, Age, Sex -- this is a STATIC data base. We might have 5 people in the database, or we might expand it to have 500; it's still the same unchanging data structure.

A dynamic database, on the other hand, is one where I've always felt had a structure built to be flexible and adaptable. If you guys remember my Homework Helper which I shared while in production (once finished, the local school purchased rights to it so I couldn't share the finished product), it relied on a dynamic database.

<President><Elected In><Elected Out> <---- It allowed the USER to create a header such as the following for their data, and it read the stuff between the brackets as individual fields, which it then used to track the actual data which followed.

When created, I had no idea what fields a teacher might want to add to make a set of test questionnaires for students to use and practice on. For our presidents, they might want name and years in office... Or they might want to add which president they were numerically (Who was the 14th president?), or what party they belonged to... I had no idea what fields the USERS might want to add to the database, so I had to create it to be flexible and dynamic to their needs.

Memory usage wasn't the least bit of a concern -- it was writing the database to the point where its STRUCTURE was fluid enough to allow field addition/editing/deletion which made me consider it to be a "dynamic database".

******************
******************

Have I just fallen out of the loop? What do you guys think of when you hear the terms? Is it honestly just the difference in how we allocate memory which designates the difference in "static vs dynamic" now? If so, then how do you differentiate between the two data types I was speaking of above? "Open vs closed data structure"?

Man, talk about something making me feel OLD....

I've worked with various databases and data styles all my life it seems, but today's the first time where it felt like I couldn't hardly even speak the same language when discussing one with a younger collage student.

Anyone else run into this conversational/generational gap? I always thought "once a computer nerd, always a computer nerd", but apparently that doesn't hold true in today's world anymore.

I'm just old....

Title: Re: Static vs Dynamic Databases
Post by: Cobalt on October 04, 2018, 01:40:31 pm

If it is a definition created by a US person or entity then the rest of the world will see it corrupted and ruined. The world hates and despises anything USA based. An individual person in that world might like the USA but, as a group or a whole they despise us something fierce and will stop at nothing to ruin everything we do. We, as in USA people in the QB64 community, have some good friends around the globe but, put them in the group and they would quickly get swallowed and quashed out. The definitions your familiar with is what I was taught too. so those definitions you found come across as quite foreign ideas to me as well.

Title: Re: Static vs Dynamic Databases
Post by: STxAxTIC on October 04, 2018, 06:37:00 pm

Heya boys,

Appreciated your comments like crazy Cobalt. To all the USA haters out there, all I can say is sucks to be you. Honestly this isn't a matter of definitions though so let us get back to the point...

So Steve - I would've felt the same way a year or two ago til I started learning about the strangely satisfying world of alternative data structures. This delves into hashing, hash functions/tables, linked lists, etc etc etc... And once that toolset is sorta understood, you look back and say to hell with old-fashioned arrays and stuff.

So REDIM doesn't really mean it makes the array dynamic in this sense. All REDIMming does is make a new static array out of an old one. A dynamic scheme will be so flexible, you could have any behavior from each row being unequal length, shuffling fields around for some records but not others, making records point around to each other in a tree-like fashion - etc etc etc... and all of this would be MAYHEM using old-fashioned arrays. I would really Wikidive this for a night.

Meanwhile, and not to self-reference, but my up-and-coming text editor shows off exactly the principle above. Namely it's a giant doubly-linked list. To explain: you know the problems with making a general-purpose textbox in qb64. All those weird cases, all the backspacing, pasting blobs of text here and there - again this is utter mayhem for normal arrays. Implement a liked list and voila, the mechanism is tight as ever... Now if I would only get around to finishing the interface...

(And re-reading this I should disclaim that I don't really know much about databases than any other layman.)

Title: Re: Static vs Dynamic Databases
Post by: bplus on October 04, 2018, 07:22:32 pm

Dynamic or static space allocation + dynamic or static structure, 4 combos but is dynamic structure possible with static space allocation? Static space allocation + static structure sounds super fast! Dynamic structure + dynamic space allocation sounds super interesting and more complex.

Call me, DY+NAM+IC ? ;D

Title: Re: Static vs Dynamic Databases
Post by: STxAxTIC on October 04, 2018, 09:01:02 pm

Quote

Dynamic or static space allocation + dynamic or static structure, 4 combos but is dynamic structure possible with static space allocation? Static space allocation + static structure sounds super fast! Dynamic structure + dynamic space allocation sounds super interesting and more complex.

Holy tongue twister! It took me two passes to realize this post wasn't a joke, and actually says (at least) two things.

Title: Re: Static vs Dynamic Databases
Post by: bplus on October 04, 2018, 09:09:08 pm

A Dynamic Do-over?

Title: Re: Static vs Dynamic Databases
Post by: Petr on October 05, 2018, 10:53:17 am

So, in fact, the dynamic field will be the same as the automatically redefined static field, but not just the size of the records in its field, but also the change in its type, right? So if the _UNSIGNED _BYTE field is with a value above 255 is then converted to _UNSIGNED INTEGER, and if it is some value over 65535, it will be converted again to _UNSIGNED LONG? Is that a dynamic field? Or it is something different?

Title: Re: Static vs Dynamic Databases
Post by: SMcNeill on October 05, 2018, 11:31:19 am

Quote from: Petr on October 05, 2018, 10:53:17 am

So, in fact, the dynamic field will be the same as the automatically redefined static field, but not just the size of the records in its field, but also the change in its type, right? So if the _UNSIGNED _BYTE field is with a value above 255 is then converted to _UNSIGNED INTEGER, and if it is some value over 65535, it will be converted again to _UNSIGNED LONG? Is that a dynamic field? Or it is something different?

When we're talking a static field, it's one that doesn't change, whereas a dynamic field may. In QB64, we see an easy example with fixed length strings vs plain strings.

DIM Array(1 TO 100) AS STRING * 10

vs

DIM Array(1 TO 100) AS STRING

The first is going to use 1000 bytes to store the data with it, so under the "new definition" my friend was using yesterday, it's a STATIC database. 1000 bytes of memory required to hold it; nothing more, nothing less.

The second, however, is going to start out blank (all elements are ""), so uses 0 bytes to store the data, but will move and alter requirements as the elements change. It may take 1000 bytes to hold the information, or it may take 100,000,000... Under the new definition, it's considered a DYNAMIC database as the memory usage may change at any time.

********************

Now, the way I was taught to label databases years ago would call both examples STATIC. The field is set -- it's a string in both cases. One may use longer/shorter strings than the other, but it's still always a string value...

From the way I was taught, DYNAMIC databases had flexible fields that changed at the USER's desire, not the programmers.

DIM M AS _MEM
M = _MEMNEW(10000)

With the above, the user could store bytes of numbers in that memblock. They could store string characters. It'd be up to THEM to define what the data inside the block represented. We'd have to code our database to allow them the flexibility to create an identifier set of headers and then enter the data that correspond to their headers. It's this flexible, alterable, user-defined method which creates what I used to know as a DYNAMIC database --- memory usage had NO part of the definition.

Either somebody changed the jargon, I fell behind the times, or my friend is an idiot... The way the two of us label "dynamic vs static" is just absurdly different. To HIM, it's all about whether the memory used can be set in stone (he calls the _MEMNEW "static" as it reserves 10000 bytes and never changes it), or if it changes (as with the AS STRING array). To ME, it's about if the fields in the database are set or variable -- which means we're not talking about the same beasts at all.

Title: Re: Static vs Dynamic Databases
Post by: SMcNeill on October 05, 2018, 12:12:30 pm

Here's a very quick and cheesy example of what I'd consider to be a "dynamic database":

First, copy this little code and save it as "temp.txt" in your QB64 folder:

Code: QB64: [Select]

word 1|ST,word 2|ST,num 1|NM,num 2|NM
dog,food,1,2
hair,ball,3,4
 

Then copy the code here and run it in QB64:

Code: QB64: [Select]

CONST FieldDelimiter = ",", FieldIdentifier = "|"
 
TYPE ArrayType
    id AS STRING * 20
    tp AS STRING * 2
END TYPE
DIM Header(1 TO 100) AS ArrayType
 
 
OPEN "temp.txt" FOR BINARY AS #1
LINE INPUT #1, Header$ 'get the header
DO 'seperate the data fields
    Elements = Elements + 1
    l = INSTR(Header$, FieldDelimiter)
    IF l THEN
        decode$ = LEFT$(Header$, l - 1)
        Header$ = MID$(Header$, l + 1)
    ELSE
        decode$ = Header$
    END IF
    l1 = INSTR(decode$, FieldIdentifier)
    Header(Elements).id = LEFT$(decode$, l1 - 1)
    Header(Elements).tp = MID$(decode$, l1 + 1)
LOOP UNTIL l = 0
 
PRINT "Your database consists of:"
FOR j = 1 TO Elements
    PRINT Header(j).id, Header(j).tp
NEXT
 
DO UNTIL EOF(1)
    Records = Records + 1 'count lines for records
    LINE INPUT #1, junk$
LOOP
CLOSE
OPEN "temp.txt" FOR INPUT AS #1 'just so I can be lazy and use INPUT without parsing fields
LINE INPUT #1, junk$
 
DIM DataArray(Records, Elements) AS STRING
FOR i = 1 TO Records
    FOR j = 1 TO Elements
        INPUT #1, DataArray(i, j)
    NEXT
NEXT
 
'And now to work with our data somewhat cheesily
FOR i = 1 TO Records
    FOR j = 1 TO Elements
        FOR k = 1 TO Elements
            PRINT "What do you get when you add "; DataArray(i, j); " and "; DataArray(i, k); "? ";
            IF Header(j).tp = "ST" AND Header(k).tp = "ST" THEN
                PRINT DataArray(i, j); DataArray(i, k)
            ELSEIF Header(j).tp = "NM" AND Header(k).tp = "NM" THEN
                PRINT VAL(DataArray(i, j)) + VAL(DataArray(i, k))
            ELSE
                PRINT "We can't add numbers and strings!"
            END IF
        NEXT
    NEXT
    SLEEP
    CLS
NEXT
 

As you can see, I've established a set of minor rules for how an user can create a database to work with this program. Name a field, then identify if it's ST or NM (string or number), then add another field by adding a comma as a separator.

Now, this is the ABSOLUTE bare bones of (what I'd call) a "dynamic database", and it has no error checking of any sort or data validation for it. IF you follow the basic rules of creation, you can make this add your elements together (if possible), no matter how you define them. It handles strings one way, numbers another, and refuses to mix the two....

YOU, as the user, can define the database to become anything you want it to be. Add a set of fields. Add records. Delete them... As the programmer, *I* have no idea what type of dataset you're going to throw at this little routine. It's completely "dynamic" and responds to YOUR, the user's, data file, as you define it.

Title: Re: Static vs Dynamic Databases
Post by: Petr on October 05, 2018, 01:08:11 pm

Thank you for the show, Steve.

Title: Re: Static vs Dynamic Databases
Post by: Pete on October 05, 2018, 05:18:28 pm

DIM Mass AS Single
DIM U Double
LET U = Mass
' Oops. Double DIM Mass on U.

Pete :D

- Kirk from Star Trek 4

Title: Re: Static vs Dynamic Databases
Post by: codeguy on October 05, 2018, 05:40:13 pm

The way I view static is that it's known at compile time and never changes lbound or ubound during execution. Dynamic is not fixed at compile time and CAN be altered during execution using redim. My sorting library and test harness use dynamic arrays. I prefer not to use many globals (CONSTs, STATIC, SHARED) as this can cause unpleasant conflicts.

Title: Re: Static vs Dynamic Databases
Post by: STxAxTIC on October 05, 2018, 06:48:48 pm

EDIT: Somehow (due to the way I enter to forum page) I missed Steve's code above. I may shove my foot in my mouth after fiddling with it, but I'll keep the meandering prose below for completeness:

(I think once again we're getting lost in what "dynamic" here means. Should we try to agree that REDIM does not mean "be dynamic"?)

To elaborate on what I meant above when hinting at the fields being different length, what that really means is not just variable-length strings in types or even a generality of that. I mean each record's type being able to differ. The first record in the database may be just a person's name, and containing nothing else. Not other fields that are left blank, I really mean the name is *it*. Meanwhile, the second entry might have a user name, address, and a handful of other fields uncommon to the other records. So you gotta imagine:

Type foo
a as string
b as integer
end type

Type bar
c as long
d as double
e as whatever
end type

coexisting in the same array... and even this example makes me cringe because it's a bit restricting. I recommend going full liberal party with how you think of data now. Scattered and unstructured, but infinitely flexible.

Title: Re: Static vs Dynamic Databases
Post by: SMcNeill on October 05, 2018, 08:04:37 pm

I've worked with databases like you mention, the way I've seen those, they often have a leading identifier field to them:

Structure would be similar to:
Identifier
Field1
Field2
Field3
So on...

In your example, Record 1's identifier might be "F1", which says it holds the name (Field 1), as you mentioned. Record 2's identifier might be "F1F2" to indicate it contains name, and address...

Other easy ways I've seen this done is with a termination field/code:

Field1
Field2
Field3
So on....
Terminator

So record 1 is "Steve:name" then CHR$(26) for the terminator. Record 2 is "Bill:name;Male:sex;123 His Home:address" then CHR$(26)...

Actually lots of ways to "Link" the fields together, but as long as they're constrained internally, I'd call it a "static database". Your example with set TYPEs is defined by the programmer and doesn't change. My definition of a "dynamic database" would be one where the user can create their own fields to suit their needs, not just add or exclude some optional preset fields. ;)

Title: Re: Static vs Dynamic Databases
Post by: STxAxTIC on October 05, 2018, 10:04:01 pm

Sigh. Hear that? It's the point sailing waaaay over. I'll try better with an example or something.

EDIT: Provided QB64 is even suitable. I mean - has anyone else bothered searching this out?

Title: Re: Static vs Dynamic Databases
Post by: codeguy on October 05, 2018, 11:05:44 pm

The only other structure I can think of that lends itself to changing is what I call a data dictionary, where the columns of rows are defined in a separate file, usually column titles first then the start and end points of each field separately or a string of spaces with some non-space character to delimit field beginnings or even endings. This type of structure can be changed easily and extended, truncated or inserted with great facility. Beyond this, I just don't understand.

Title: Re: Static vs Dynamic Databases
Post by: TempodiBasic on October 06, 2018, 11:01:24 am

Hi Guys
thanks to let me learn and think about a DATA STRUCTURES.

following yours different approaches and thoughts I can think this about Static and Dynamic structures

see attachment

Thanks for feedback

Title: Re: Static vs Dynamic Databases
Post by: luke on October 08, 2018, 04:28:18 am

Side note: the static vs dynamic array distinction was more important in quick basic, where there was all kinds of voodoo regarding which memory segment your array was in and whether it could be > 64KB. Now days none of that matters, and the biggest difference is whether you can resize it or not.

My (un)professional opinion is that dynamically declared arrays are the bees knees and just better in every way.

Title: Re: Static vs Dynamic Databases
Post by: Pete on October 08, 2018, 08:36:19 am

Yep, QuickBASIC memory tricks. Running out of memory? Just use $DYNAMIC meta command to squeeze a little more code into your limit up programs. Usually programs in the high 50's to low 60K had memory issues. Multi-modular programming was a way out for larger apps. QB64 does not support multi-modular programming.

Title: Re: Static vs Dynamic Databases
Post by: FellippeHeitor on October 08, 2018, 08:44:38 am

Doesn't it?

Title: Re: Static vs Dynamic Databases
Post by: Pete on October 08, 2018, 04:00:43 pm

Don't you have better things to worry about, like if Brazilians are going to elect a racist, misogynist, homophobic, xenophobic, torture supporting, gun totting, far-right military dictator as President? Or... if you're just going to stick with a normal government made up of liberal minded criminals who drive the population to vote for a racist, misogynist, homophobic, xenophobic, torture supporting, gun totting, far-right military dictator? And I thought we had it bad in the U.S.; good luck with process, which I'm sure the news here is co-opting for our own political muck-racking.

But if you do have time... Didn't Rob state he would not incorporate QuickBASIC multi-modular programming into QB64? I started grouping all my office programs into one, because of that decision he made some 7 or so years ago. I don't see a "Load Module" command in the IDE, so I doubt it. Multi-level modules treated global variable differently, but my memory cann't recall specifics anymore. There were some advantages and disadvantages because of these differences but I recall I had to make a lot of variable changes to my modules to merge them into single programs.

Pete

Title: Re: Static vs Dynamic Databases
Post by: STxAxTIC on October 08, 2018, 04:02:02 pm

I think Fellippe just means you can $include BI and BM files in the main BAS program, amirite?

Title: Re: Static vs Dynamic Databases
Post by: SMcNeill on October 08, 2018, 04:02:53 pm

Quote from: STxAxTIC on October 08, 2018, 04:02:02 pm

I think Fellippe just means you can $include BI and BM files in the main BAS program, amirite?

But Pete's talking more about CHAIN style programs, I think.

Title: Re: Static vs Dynamic Databases
Post by: FellippeHeitor on October 08, 2018, 04:43:31 pm

Last I checked QB64 had CHAIN implemented.

I could be wrong.

Title: Re: Static vs Dynamic Databases
Post by: FellippeHeitor on October 08, 2018, 04:45:10 pm

Also COMMON SHARED.

I could be wrong here too.

Title: Re: Static vs Dynamic Databases
Post by: Pete on October 08, 2018, 05:01:19 pm

Clippy always used CHAIN, I never did. I transferred data in files and ran one app to another in the old days.

Multi-modular programming was a way a single QB program could be increased from a max of 64K to 200+K. I recall one of my largest was 5 50K+ programs put together in modules. The QB IDE allowed you to save and load these modules into the IDE and run the whole thing emulated. If I recall correctly, COMMON SHARED did NOT cross modules. So if you had main.bas, m1.bas, m2.bas, etc. each module could have COMMON SHARED a$ in it but it would only be shared among the subs and functions within that module. So if a$ + "Pete" in the main.bas module and a procedure in the main.bas module called a procedure in a different module, you had to remember to pass the a$ variable, or it would be lost. Anyway, Rob did implement COMMON SHARED but not multi-modular programming. Multi-modules also prevent duplicate definitions, etc. Truth be told, it allowed for sloppy programming but it was a complete blessing when I hit the memory wall back in the day.

Pete

Title: Re: Static vs Dynamic Databases
Post by: SMcNeill on October 08, 2018, 05:38:31 pm

QBASIC Modules explained: http://www.infinitefactors.org/jonk/modules.html

Title: Re: Static vs Dynamic Databases
Post by: TempodiBasic on October 08, 2018, 07:15:23 pm

Yep
I remember that days in which I wrote my first (not the only?) program multimodular using CHAIN and COMMON SHARED keywords...
how many headaches until I understood that the COMMON SHARED area must be the same in the two o more files of the program.
If you just change the order of the variables declared in the common shared this gives you so many headaches!!!

Title: Re: Static vs Dynamic Databases
Post by: TempodiBasic on October 12, 2018, 08:27:11 am

Hi Guys
just a little test about COMMON SHARED and CHAIN vs $INCLUDE

if you are patient please copy and paste these code and save as named in sequence in this post

Quote

modulo1_.bas

Code: QB64: [Select]

'COMMON       REM NOT NEEDED IN $INCLUDE WAY
DIM SHARED a1 AS INTEGER, b2 AS STRING
PRINT "modulo 1"
a1 = 10
b2 = "I am here!"
PRINT a1, b2
'CHAIN "modulo2"     REM NOT NEEDED IN $INCLUDE way
'$INCLUDE:'MODULO2_.BAS'
PRINT "modulo 1" ' all this part of the code will never run IN COMMON way
PRINT a1, b2
END
 

Quote

modulo2_.bas

Code: QB64: [Select]

'COMMON SHARED a1 AS INTEGER, b2 AS STRING       REM NO NEEDED IN $INCLUDE way
PRINT "modulo 2"
PRINT a1, b2
SLEEP 3
a1 = 8
b2 = "sono di ritorno"
 

Quote

modulo1.bas

Code: QB64: [Select]

COMMON SHARED a1 AS INTEGER, b2 AS STRING
PRINT "modulo 1"
a1 = 10
b2 = "I am here!"
PRINT a1, b2
CHAIN "modulo2"
PRINT "modulo 1" ' all this part of the code will never run
PRINT a1, b2
END
 

Quote

modulo2.bas

Code: QB64: [Select]

COMMON SHARED a1 AS INTEGER, b2 AS STRING
PRINT "modulo 2"
PRINT a1, b2
SLEEP 3
a1 = 8
b2 = "sono di ritorno"
 

Otherwise you can see this pictures of results to see differences among the two methods

Good Coding

Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: SMcNeill on October 04, 2018, 01:26:37 pm