Just recently the great and good have been telling people on LinkedIn about their first day at work. I don’t want to feel left out, so I thought I share what I remember about my first day at work. Actually, I’ve had several starts, all in different locations and under different circumstances. If you like, this is the “first, first”!
The job was supposed to be a fill-in while I retook an exam to improve on the grades which I needed to get into the university course I wanted . I remember that I had been given no notice of the interview – quite literally I had been asked “Can you go NOW?” and I’d gone – THEN! I had been unkempt and unshaven. The interview was on a Wednesday or Thursday and I must have said the right things, because they asked me if I could start on the following Monday.
The job was as a lab assistant in a small research laboratory. My responsibilities were to be quite varied, basically: do as you’re told by your superiors (which meant almost everyone else!). I thought of it as being “bottle-washer”.
On the Monday, the post arrived as I was about to set off for work. It contained an unconditional offer for the university course I wanted. They said they thought I could cope with the grades I had. So, I turned up on my first day at work and handed in my notice!
In fact, I told my new employer that if they preferred, I would “not start at all” and we could call the whole thing quits. They were really decent about it and said that I could have the job until I was due to go to university. Excellent I thought: relevant experience and two months of pay. Just the start I needed.
My job really was “washing bottles”, and test-tubes and beakers and flasks and all the other paraphernalia of a chemical laboratory. I had to learn pretty quickly that we had some real nasties. I spent at least some of my time working with chromic acid which is really not good to come in contact with. One of the things we worked with was ion exchange resin which came as tiny polystyrene beads. I had to be really careful not to spill any of the wet beads on the floor because when they dried they became like little ball-bearings and on a hard lino floor the effect could be really quite dangerous.
Some pleasant memories are:
- Being told off because “I walked like the lab manager” and the sound of my footsteps made some of my colleagues uneasy (to this day, I don’t know what they were up to).
- Playing cricket in the park opposite the lab during lunch break. The wickets were old retort stands and the bat was kept in one of the equipment drawers.
- And playing cards with the other workers on the wet lunch breaks.
Less pleasant memories are:
- Doing seemingly endless titrations to get the “break-through point” on a sample ion exchange resin,
- And the smell of the Amination Room where we kept the fume cupboards and unpleasant materials.
- “The Cloud will cost x” (per user/month), but how much does my server actually cost me?
- For that matter, how much is all that data worth (to me)?
- For many situations a constraint is redundant. The fundamental structure of many applications means they are unlikely to create orphan rows.
- The cost of the constraint is in the extra processing it causes during update operations. This cost is incurred every time a value in the constrained column is updated.
- The benefit of a constraint is that it absolutely protects the constrained column from rogue values. This may be particularly relevant if the system has components (such as load utilities or interfaces with other systems) which by-pass the normal business transactions.
- Other benefits of constraints are that they unequivocally state the “intention” of a relationship between tables and they allow diagramming tools which navigate the relationships to “do their thing”. Constraints provide good documentation, which is securely integrated with the database itself.
- The costs of constraints are small, but constant and in the immediate term.
- The benefits of constraints are avoiding a potentially large cost, but all in the future.
More Detailed Argument
- we create or update the ORDER and ORDER_LINE entities, and
- in addition we refer to PRODUCT (to get availability and Price) and presumably to the CUSTOMER entity which isn’t shown on the diagram.
What’s the problem?
- Preparation: Collect any documentation
- “Brainstorm:” Try to guess the tables/entities you will find in the database.
- List the actual Tables
- Group the Tables: based on name
- For each “chunk”, do the following:
- Identify “keys” for tables: Look for Unique indexes.
- Identify candidate relationships: Based on attribute names, and non-unique indexes.
- Draw your relationships.
- “Push out” any tables that don’t fit.
- Move on to the next group.
- When you’ve done all the groups, look for relationships from a table in one group to a table in another.
- Now try and bring in tables that were “pushed out”, or are in the “Miscellaneous” bucket.
- Repeat until you have accounted for all the tables.
The method stages in more detail.
List the tables:
Group the tables
Identify the candidate keys, and foreign keys from the indexes
From attribute names and indexes, identify relationships
- Sometimes the index names are a give-way (FK_…)
- Sometimes you have to look for similar column names (ORDER_LINE.ORDER_ID à ORDER.ID)
- Multi-part indexes sometimes indicate hierarchies.
Look for “Inter.group” Relationships