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 14 in printed book and digital formats -- plus a one-year subscription 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 12.1 ('Smart Localization')
Instant purchase and download via GumRoad!

COLUMN

Database Standards

Databases are code too and should be treated that way

Issue: 12.1 (January/February 2014)
Author: Craig Boyd
Author Bio: Craig Boyd is currently an Oracle DBA for a well-known national retailer. But in his 17 years of IT experience, he has been everything from a PC Technician, iSeries System Administrator, iSeries Programmer, Sr. Technical Lead, and Data Modeler. He lives in the great state of Texas with his wife and two kids.
Article Description: No description available.
Article Length (in bytes): 8,333
Starting Page Number: 75
Article Number: 12110
Related Link(s): None

Excerpt of article text...

I think most of us would agree that standards and consistency are important. The longer we code we get into habits of naming variables, methods, classes, objects, etc. When we work in groups or teams we create a standards document so that we all code the same way. Why? Because it makes everyone's life much easier. I can pick up Joe's code when he goes out for a two-week vacation and not have to wonder what Vx779 means. It makes it easier to understand the other person's logic when I don't have to spend time decoding method, class, variable, or object names. This also means that when a new person comes into the group they can be brought up to speed much sooner. Standards make code reviews easier for all the above reasons. Time can be spent on how to optimize code or learn new tricks from other developers instead of spending the time decoding the code and THEN trying to understand it.

The same can be said for database design.

Let's take the new guy joining the team example. You give him the coding standards document and tell him to read it and learn it. Then you show them how to pull code from your source code repository. Things are going pretty well. Then you ask him to build a maintenance screen for a transaction table that is about thirty-five columns wide. You give him the connection parameters to the development database. He connects and runs a couple SQL SELECT statements. The results are what you see in Figure 1.

The resulting conversion goes like this:

JR: So where is the documentation on the database?

SR: ...

...End of Excerpt. Please purchase the magazine to read the full article.