Choosing the right processor to buy

Computers and their parts are filled with millions of jargon's and specs making it difficult to understand them and find the right device for the right job. Let us shed some light into understanding the specifications of the core component of your computer - "the processor alias CPU"

The number of bits 32 bit vs 64 bit:
If you have not studied computer architecture this is definitely confusing for you. When you walk into buy a CPU the vendor will say that 64 bit is better than 32 bit, but you notice its costlier and you are unsure if you need it. Let us understand that by going for higher number of bits we have following advantages:

• More bits means that data can be processed in larger chunks which also means more accurately.
• More bits means our system can point to or address a larger number of locations in physical memory.

32-bit systems were once desired because they could address (point to) 4 Gigabytes (GB) of memory in one go. Some modern applications require more than 4 GB of memory to complete their tasks so 64-bit systems are now becoming more attractive because they can potentially address up to 4 billion times that many locations.

When should you actually buy a 64 bit CPU?

1. You are going to buy/have a 64 bit OS (yes operating systems also come in variants)
2. You are going to buy/are considering to have more than 4 GB of RAM
3. You use/going to use 64 bit applications (eg: Adobe creative suite, Half Life 2)
4. You are going to use virtualization and install multiple OS on top 

 Balancing the number of cores and the clock(GHz):
Go ask you friend who is a hardware engineer which is better a single core 3.2 GHz or dual core 1.6 GHz processor? If he is smart he will say the the single core one even tough the dual core one is effectively 1.6*2=3.2 because a considerable delay is caused because of needing to synchronize two processors. Don't agree? Try asking two people to work together on one person's job. If you enable Hyper-threading on the single core and change the two core configuration to 1.8 GHz and ask him what is better, I bet you he will scratch his head and say depends. A usefulness of a multi core configuration is dependent on the way you use you computer. So get a lot more cores (4-8) if you do the following

• Watch a movie or play a game while there is some background work like video encoding going on on you machine
• You are hosting multiple web/ftp/db servers on your machine that continuously take a lot of requests

Take lot of cores if you multi task and/or use programs that use the multiple cores to work faster(most programs aren't that optimized yet).  Otherwise Dave one or two cores ought to be fine for you.
Power consumption:
Probably one of the most important spec that is mostly forgotten to check by people is power consumption. This is very important especially if you processor sits on a laptop. More GHz/cores implies higher power consumption and can really drain your battery quickly. So you should find the right balance between power and power consumption. So when you compare two similarly configured intel core i3 and an intel core two duo you will find that the intel core i3 has a phenomenal drop in power consumption (30W isn't at a small drop)
Cache size:
Probably the only part of the specification that follows the real higher the better moto. Read more about it here 

Understanding closure of functional dependencies

Understanding functional dependencies and closure gives you great power in designing or analyzing database schema. If you are new to functional dependencies you can read them up from here.

What is closure?

The closure of a set F of functional dependencies is the set of all functional dependencies logically implied by F.

What can we do by knowing closure?

We can find out several things about the relational database by knowing closure properties. I will list a few of these:

• Finding a key for the relational schema: If we go through the closures of all elements in the functional dependency, the element for which the closure encompasses all the elements of the relation is the database key
• Finding if a relation having composite candidate key is in 2NF (we only consider the composite case because  when a 1NF table has no composite candidate keys (candidate keys consisting of more than one attribute), the table is automatically in 2NF): If we take closure of a part of the key then there must not be any element other than itself in it. This ensures that all elements are dependent on the complete key itself

How to find closure?

I have written a tool for this which you can pick up from github . Also you can read about it here and also go through the example below.

To understand closure let us take an example of a relational database that stores a employee information. Let the fields in this relation be EID, NAME, ROLE, DIVISION,SALARY

For this we can logically see the following functional dependencies:
EID->NAME #every employee has a unique id
ROLE,DIVISION->SALARY #An employee's salary is determined by where he works and his role
EID,NAME->ROLE #Employee can have only one role
EID,NAME->DIVISION #Employee can work for only one division

1. Let us validate using closure of the field EID whether EID is actually the key. Since we start with EID, our closure is initialized with {EID}.
2.  Going through all the functional dependencies we see that attribute NAME depends on EID which is already in our closure set. We can add this and update our closure set to {EID,NAME}
3. Now going through all functional dependencies again we see that we have ROLE dependent on EID and NAME (both already in closure set) and add ROLE to closure set.
4. Traversing again we see SALARY dependent on ROLE and DIVISION but we skip it as DIVISION is not in our set yet.
5. We see that DIVISION depends on EID and NAME and add it to our closure set to make it {EID,NAME,ROLE,DIVISION}
6. Traversing again we see that we can add SALARY now as both ROLE and DIVISION are already in the closure making our closure {EID,NAME,ROLE,DIVISION,SALARY}
7. We end our traversal when we have no more additions to make
8. Thus looking at our closure we see indeed that EID is fit to be the primary key.