Defining Database Tables (part 1)

 Welcome back!

In this blog entry we will begin the definition of a Table DB Module, which will be built on top of our DB Module.

As you will remember the DB Module is the lowest level Module in our Database Layer. He is the only module who interacts with the database, no other module in your application should directly touch the database.

Now I will begin the definition of the Modules who sit atop DB. There are three distinct table Structures that have to be considered. 

  • Single, or stand-alone, Table - examples of this the bottom Module of the Parent Child Structure, or and Class which has No Children.  A Static list of Values, a List of Error Codes. This is often referred to an "is a" paradigm. if an object is a ErrorType, where ErrorType is Not a child.
  • Parent-Child Table - A great example of this would be Galaxy, a Galaxy has Many SolarSystems, each SolarSystem has many Planets, Each Planet has Many Factories.  As you can see the Parent Child Table Structure is best described as the "Has A" paradigm.  
  • Many to Many Tables - This is a more complex hybrid of the Parent Child, where in Each Record of one table can relate to one or more records of another. This Relationship model requires the use of a Cross-Reference Table, I like to name these as "Xref" Tables.
I will over the next few blog entries explain these table Models further as I show you how to deal with each from a code perspective. Finally, at the end of this series of blogs I will introduce you to a Product which greatly assists you in developing your Database Layer. 



Comments

Post a Comment

Popular posts from this blog

How to build this without writing Code

I'm not sure if I should do this now, because I have not explained a number of additional aspects to the code, but for those of you who are interested.  The foundation of what I shown you here, IS the foundation of code my PBXClassBuilder-Standard generates for you.  And I truly mean generates  for you. You can have all this code generated for you without writing a single line of it yourself. Now PBXClassBuilder-Standard is not perfect, it is approximately 90=95% accurate. And I am constantly tweaking it edging this number ever higher. To use PBXClassBuilder-Standard, You should start with Forms already laid out and built.  Within PBXClassBuilder-Standard you use intuitive screens to define your table structure, while linking the Table Fields to their intended form Fields.  Then link the Tables together as Parent Child, and finally you simply click buttons to generate the code, Including the SQL Code to create the tables. The Whole development process, post For...
Read more

Connecting the Forms to the Data-Layer (part 9)

Here is the whole View Code Sheet Define quitfrmSolarSystem Declare SolarSystemCustom() Declare SolarSystemSetScreen() Declare SolarSystemCreate() Declare SolarSystemModify() Declare SolarSystemDelete() Declare SolarSystemSetData() Declare SolarSystemSave() Declare SolarSystemClose() Procedure SolarSystemSetScreen() Protected String$, x, y, w, h, i, ID Shared WorkSolarSystem Protected EventID, MenuID, GadgetID, WindowID, Index Shared quitfrmSolarSystem quitfrmSolarSystem = #False If Window_frmSolarSystem() SolarSystemCustom() SetActiveWindow(#Window_frmSolarSystem) ;Set Screen Data SetGadgetText(#Gadget_frmSolarSystem_txtName, WorkSolarSystem\Name) SetGadgetText(#Gadget_frmSolarSystem_txtGrow, Str(WorkSolarSystem\GRow)) SetGadgetText(#Gadget_frmSolarSystem_txtGCol, Str(WorkSolarSystem\GCol)) SetActiveGadget(#Gadget_frmSolarSystem_txtName) Repeat EventID =WaitWindowEvent() MenuID =EventMenu() GadgetID =EventG...
Read more

Connecting the Forms to the Data-Layer (part 8)

 So now we are down to just the SolarSystem Code Sheet. This is NOT a rubberstamp of the Galaxy. The MAIN reason is that the Galaxy Records are Sourced directly from the Database, As you will recall our SolarSystem is Sourced from the Galaxy Record's Solar System Collection NOT the Database. This makes for a VERY Significant difference between in the code. Our Procedure are the save ALL the Steps are the same, the differences are in the details. Starting once again at the top, we have our declares: Define quitfrmSolarSystem Declare SolarSystemCustom() Declare SolarSystemSetScreen() Declare SolarSystemCreate() Declare SolarSystemModify() Declare SolarSystemDelete() Declare SolarSystemSetData() Declare SolarSystemSave() Declare SolarSystemClose() And then, as before the SetScreen Procedure, and Control-Loop. Procedure SolarSystemSetScreen() Protected String$, x, y, w, h, i, ID Shared WorkSolarSystem Protected EventID, MenuID, GadgetID, WindowID, Index Shared quitfrm...
Read more