SLOS’s from inside – Life scenarios – Part IV

“So dream when the day is through
Dream, and they might come true
Things never are as bad as they seem
So dream, dream, dream”

«Dream» – Frank Sinatra

Before we begin discussing the mysterious ‘LL’ mentioned at the end of the previous post, it would be good to finish this series of articles on SLOS’s and look at them in depth, dreaming about their ‘perfect’ inner coordination.

In our system every list is contained within its’ own table. Right now we have around 40-50. This is of course a big heap of a nuisance but oh well. This is the case when you add one table at a time thinking it is the last one and don’t notice when they become a pile. Each table has a specific structure that corresponds to the type of list (SLOS, SLOSW, SLOSD or SLOSWD). Only one PHP class is used to manage all types of lists. It receives the name of the table (you can get the structure by its name) and labels to display. For example, the table is called [diagnose_type], but the heading needs to be ‘Diagnosis’.

Common format of these tables is:

Figure 1 This is how we store lists

To move a pile of tables into one table is pretty easy, just as easy as to rewrite PHP class, but changing the way lists work in each application is a time consuming job especially in a lack of time. That’s how we live, opening the door, chucking another table in and snapping it shut again so nothing pours out. But no one can stop us from dreaming so the next part of this article will be about an ideal, but not yet implemented way of lists handling.

“If only we could start building the system from scratch”. These words are used by system developers a lot more often than it is thought to be. We use these words very often, due to the fact that we have been working on a very big system for the last 8 years, what about you?

So, let’s begin dreaming…

- Let’s create one big table, – drawling one of us, starting tuning himself into visionary mood.

- Why one? – asks the second one, who wants to doubt and re-check everything.

- Where will the names of the lists be stored, analogies of tables names in current implementation? – says the second.

- Can you recall how those vendors store lists, the ones that sell their systems for millions of dollars to our client, and with which we had to integrate (after re-reading The Kama-Sutra), – says the first, making to-and-from hands motions, firmly staying in a dreaming mood.

- You know you’re right; they all had one table with a column dedicated to store a list name in it. ‘DIAGNOSE_TYPE’ would be repeated cell after cell for all list values. De-normalization for optimization? – rhetorically asks the second.

- Exactly so, – nods the first.

- Be like them we will not! – accenting on the last word to annoy the first says the second and draws two tables on the board after all.

- We strive to produce not just a result, we adhere to this – the second finishes drawing the tables, sending the URL of our adherence principle to the first using a new product that just got out on the market – iBrain (first reads the writing on the picture in the link and begins to laugh).

Figure 2 Drawn by the second on the board

When the name of a list is stored with all its’ values, this means that the architect is lazy to JOIN every time, when you need to get a value by list name kept in a separate table. It also means that he doesn’t assume that it could be a requirement to have an empty list in a system. We haven’t met such requirement yet. Each list in our system has to have at least one value or ‘Configuration error’ message will be shown.

Figure 3

What other information would it be nice to have? We are determining what type of list we are going to work with by the table structure now. When everything is moved into two tables we need to store this information somewhere. If we would create only one table, then this would have been another de-normalized column with values like ‘SLOS’ or ‘SLOSWD’. However, in two tables approach, list name and list type are stored in one table while the values are kept in another one.

The more the system becomes universal the more obvious become the advantages of using two tables. Speeding through their thoughts, our the first and the second have decided to add list name visible to users – ‘Diagnoses’ into the table [list]. Soon after they recalled SalesForce interface and happily added the singular value ‘Diagnosis’ to use it for labels, tabs etc.

Some people might recommend adding some other attributes (currency, integers, letters), and also validation rules (lots of money, eight numbers, four letters), but our the first and the second aren’t persuaded because our lists sharpened for text only and have no validation rules except maybe two universal ones; a new value cannot be empty and match the other existing value in the same list. Let’s call them practical dreamers, they won’t mind.

Then the phone rang. Where from? From India, offering some services, some sort of optimization of ways we can be searched but found.
After hearing some English language and putting the phone down our practical dreamers exchanged looks, nodded as good as a wink and decided to add multi-language support into already created concept. Ultimately, it is a real life requirement to diagnose patients from within transnational corporations in English, Japanese, and Spanish languages.

In summary everything worked out into this:

Figure 4

Print this post | Home

Comments are closed.