Article Preview
Buy Now
COLUMN
Database Rules
A few things to always remember
Issue: 16.6 (November/December 2018)
Author: Craig Boyd
Author Bio: Craig Boyd is currently a data architect for a major fashion retail brand. But in his 23 years of IT experience, he has been everything from a PC Technician, iSeries System Administrator, iSeries Programmer, Sr. Technical Lead, Data Modeler, Data Architect, Oracle DBA, BI Consultant and Solution Architect. He lives in the great state of Texas with his wife and two kids.
Article Description: No description available.
Article Length (in bytes): 10,397
Starting Page Number: 88
Article Number: 16607
Related Link(s): None
Excerpt of article text...
Well, everyone... this is my final database column. I have truly enjoyed this journey with each of you. I have learned more about every database topic I have written about and I hope that I have at least occasionally been helpful to you. My life has taken some turns that require me to focus on some other things. I still plan to pop in on the Xojo forum from time to time and I hope to make a few (many?) more Xojo conferences.
Since this is my last database column I thought I would touch on a few things that I have covered before that might save you a little time down the road.
Take the Time to Design
In more than one column I have stressed the need for taking the time to design your database. It doesn't matter how cheap or expensive the tool is that you use: what is important is that you plan out how you will store the data in your application. The design will directly impact performance and how easy or difficult it is to actually maintain the database. So here are some general design principles that will go a long way in keeping you out of trouble.
Each table should store only the data that directly relates to that particular concept.
If you have a
CUSTOMERtable, it makes sense to store name, gender, eye color, life to date sales totals, etc. It does not make sense to store an array of their transactions in a clob field for each customer. Let the transactions live in the transaction tables. You have learned in OOP not to try to create classes that have everything baked into them. Instead, you create a class and limit it to the particular "thing" that you are trying to programmatically model. The same is true for database tables.
...End of Excerpt. Please purchase the magazine to read the full article.