However, we can probably
add columns to tables without causing too much backlash, and we can certainly add data
as needed.
Our development and production database systems are SQL Server systems and have
hundreds of tables already, but for our interests, we are concerned with only a couple of them
right now.
?– Note Our examples are using SQL Server data stores for our own simplicity during our writing and testing
process, but the theory and details listed should work across all systems unless otherwise noted. If you are
comfortable with migrations as discussed in Chapter 3, you may even want to do your development in one
DBMS, such as MySQL, and release to another DBMS, such as Oracle, for your production system.
CHAPTER 7 ?– WORKING WITH LEGACY SCHEMA 173
Our first example table is a members table. The members table is where we store all the basic
member information like username, password, name, and e-mail address (though we will
probably want to refer to it as an account table for our needs). The table is defined with the following
basic properties:
# members table, basic plain-English definition of fields
Members_ID, int, auto-incremented, primary key
Members_Name, varchar
Members_Email, varchar
Members_Username, varchar
Members_Password, varchar
We also are interested in a comments table that stores user comments.
Pages:
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394