Special

Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 21 in printed book and digital formats -- plus a one-year subscription (beginning with 22.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview


Buy Now

Issue 16.6 ('Munich 2018')
Instant purchase and download via GumRoad!

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 CUSTOMER table, 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.