හර්දය සාක්ෂිය

තල් වැට එපිට උන්ගේ
මරනයේ හර්දය සාක්ෂිය
දකුනේ වීදි පුරා
ගොඩනැගි ලිප්ගල් මැද
පිලිස්සි යාමෙන්
ඉක්බිතිව

ෂේෂ වූ අගුරු කැටයකින්
දකුන ලියයි...
සියතින්ම මරා දැමු
ස්වකීය හර්දය සාක්ෂියේ
නව්ය නොවූ පරිඡ්ඡෙදය
මෙලසින්

පැහැරගැනීම්...
වධදීම්...
මරදැමීම්...
නවත්වව්.

-සුසිත විජේමුණි

රාවය පුවත් පතෙන් උපුටා ගත්තෙමි.

DB Schema Design

We were in the middle of a DB Schema review and I thought of discussing some important points from it. You may have many more important things to add as well, so pls feel free.

1. Identify the Parent Table. It's good to identify whether your schema has a parent table or not. There could even be contention for the Parent table and then you have to decide whether you have multiple parent tables or not.

2. It's probably sensible to keep some tables in de-normalized form. Specially if your system is in the need of faster searches etc...

3. The tables should not contain any derivative fields. Eg: If for an event table start_date and end_date is included, do NOT include number_of_days as another field.

4. Its sensible to name the Primary Key column of each table as 'Id'. Also name each foreign key column as Id. Eg: If you have a School and Student tables where School has many students, Student can have Id and SchoolId columns. This could be specially useful for SQLGeneration logic later in the product life cycle if you do this consistently across each table.

5. Provide provisions for future extension or integrations to the system. If some of the tables (content) has a potential to be replaced by an external system(s) later in the life cycle, try to keep those tables isolated from your main tables by introducing a mapping table in between.
Eg: Assume that your crm system is capable of integrating with different ERP systems. Your system might anyway have to keep some information from ERP system duplicated in your system for ease of search etc... In this case it's not advisable to keep those tables tightly integrated to your main tables. The trick is to use an intermediate mapping table like ERPRef with an id and the rest of the fields keeping relevant ERP data together. May be you can just keep set of ERP specific Ids so that when u need data you can go and fetch it. Also you can have other base data in de-normalized form in this table to facilitate some heavyly used search within your system boundaries.

This would be the table facing heavy changes when your crm system is integrated with different ERP systems, isolating the core tables in your system.

For an example this table can have id,erp_ordertable_id, erp_account_id, suppliername, suppliercategory etc...

Then they came for you....updated

I published the following poem on this blog on 1/13/09 after Lasanthas killing

First they came for the Jews
and I did not speak out because I was not a Jew.

Then they came for the Communists
and I did not speak out because I was not a Communist.

Then they came for the trade unionists
and I did not speak out because I was not a trade unionist.

Then they came for me
and there was no one left to speak out for me
German Theologian,
Martin Niemöller
@ the time of the Great Holocaust

I found a slightly updated one reflecting on the changes happened in our 'Kingdom' during the last few months.

When those ‘civilians’ were killed in numbers, you didn’t speak up because your kith and kin were not amongst them.

Then they came for the journalists, you didn’t speak up because those journalists were betraying the motherland for chunks of dollars.

Then they came for the underworld gangsters, you didn’t speak up because they were already a menace to the society.

Then they came for opposition politicians, you didn’t speak up because of the simple arithmetic of (opposition politicians = traitors).

Then they came for you. But don’t worry. You are a patriot and you have a King to speak up for you. Long live the King!

From 'Thoughts of a Pessimist'