Database Design Guide — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A table holds one kind of fact

Design is the decision about what a row means. A table that holds two different facts will grow columns nobody can update safely. The diagram tool turns SQL you already wrote into a picture. The DDL tool turns a picture into a draft. A draft is not a migration until the migration guide says so.

Every table you mean to join has a key you can say aloud. A natural key is fine when it is stable. A surrogate key is fine when the natural value changes. Write which you chose and why. A table with no key is a spreadsheet you have not finished.

Names are part of the design. A column called data or value or flag will be guessed wrong. Use words from the job. The same word means the same thing in every table. A customer id in one table and a client id in the next, for the same person, is two designs.

Null is a decision. If a column may be missing, say what missing means. If it must be present, say so in the table, not only in the application. A constraint the application forgets is the one you wanted.

Three tables, one diagram, one draft you can read

Pick one lab fact: an order has a customer and a few lines. Three tables are enough. Draw them, or write the create statements and let the diagram tool show them back. If the picture has a line you cannot explain, remove the line.

Add the keys and one foreign key. Create the tables on the lab. Insert two customers and three lines by hand. A select that joins them returns the rows you typed. That is the proof the design holds one fact.

Write what you refused. A column for notes that will later hold a second address is a column you did not add. A table for every screen in the application is a table you did not add. The application can wait.

The DDL draft stays in the ticket with the picture. Production gets this shape through the migration guide, after a backup. You do not create tables on the live database because the picture looked finished.

A change you can finish

The lab has the three tables. Production is unchanged in this window.

Rollback on the lab is dropping those lab tables, which hold only rows you typed. Rollback on production does not apply because you did not touch it.

Name the one fact the tables will hold.
List three tables and the key of each.
Draw or generate the picture and read every line.
Create them on the lab only.
Insert a few rows you typed and join them.
Record the names and the keys in the ticket.
Hand any production change to the migration guide.

Mistakes that outlive the command

database design fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

A table with two unrelated facts.
No key, because the application will cope.
Names that only the author understands.
A foreign key that points at a column you cannot explain.
Creating the tables on production from a draft.
A diagram generated from a script you did not read.
Null used as a second meaning you did not write down.
Forty tables in the first hour.
A customer extract used as sample rows.
Calling the picture a migration.

Decisions to write down before the window

One decision for database design: The fact fits in one sentence. Each table has a key you can name. Column names use the job's words. Null, if allowed, has a written meaning. The picture and the DDL agree. The lab join returns the rows you inserted. Sample rows are fake. Production is untouched. The migration guide owns the later change. A second person can point at the key. You refused at least one extra table. And the SQL guide owns the statements. This page owns the shape.

The hour you stop

Write the database name, the host, and the clock time before you change anything for database design. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. database design is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Design checks before anyone calls the model done

Confirm this before you call the change done: Three or fewer tables were created. They exist only on the lab. Each has a key. The join returns the rows you typed. The picture matches the tables. Names are readable without you in the room. No customer data was loaded. A refused idea is written down. The DDL is in the ticket. A second person explained one relationship. Production still has its previous shape. The next table is a later ticket. The hostname in the prompt matches the hostname in the ticket for database design. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database design happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.