Phone Wallpaper

Desember 31, 2007 | | 0 komentar

Wallpaper yang cocok untuk handphone Anda, Love Nature

Game Pack For Nokia, SE dan Motorola

Desember 31, 2007 | | 0 komentar

285 java games pack 1
http://rapidshare.com/files/48020033/motorola_games.rar

40+ java games pack 2
http://rapidshare.com/files/51199985...Games_Pack.rar

1000 java games pack 3
http://rapidshare.com/files/51214755...java_games.rar

300+ java games pack 4
http://rapidshare.com/files/52320480/Nokia_Games.rar

Nokia Games 2007 Pack

Desember 31, 2007 | | 0 komentar

File Size : 11058 KB

Games included:

SEGA Football Manager, Quiz Shrek The Third, Siberian Strike, SkyForce SkyForce Reloaded Sonic Jump, Spider Man 3, Starship Troopers, Roughnecks, SuperMiners Surfs Up, Tetris Mania, The SIMS 2, THQ Wireless Worms 2007, Tony Hawks Project 8, Tornado Mania, Ultimate Street Football, World Series of Poker - Texas Hold'em Zingles

Password : zade12

Sport Formula Extreme

Desember 31, 2007 | | 0 komentar

Kepingin balapan ala F1 di HP kamu. Coba game yang satu ini. Download dulu ya ..

- 2 different One Player modes - Season 2007 and Grand Prix, - multiYou! Bluetooth mode allows 2 players to race against each other, - 17 tracks designed on the base of the existing ones, - 3 sceneries with a variety of weather conditions, - 11 teams and bolides to choose from, - different kinds of tires to choose from and the option to set the spoilers, - racing against time at pitstop, - 5 exciting music tracks.

Compatibles Support:

* Sony Ericsson: k750i and all other phones which have 176*220 resolution.

* Nokia: 3230, 3250, 3600, 3620, 3650, 3660, 5500, 6260, 6600, 6620, 6630, 6670, 6680, 6681, 6682, 7610, 7650, E60, E61, E70, N70, N71, N72, N73, N80, N90, N91, N92, N93.

Download Game Dan Aplikasi Symbian 60

Desember 31, 2007 | | 0 komentar

File Size :104857 KB

Buat kamu yang lagi cari game-game S60. Yang ini gamenya juga jumlahnya ribuan. Kamu bisa download pada alamat url di bawah :

http://rapidshare.com/files/18119065/1600_____ae______________series_60.part1.rar

http://rapidshare.com/files/18120440/1600_____ae______________series_60.part2.rar

http://rapidshare.com/files/18121884/1600_____ae______________series_60.part3.rar

http://rapidshare.com/files/18123215/1600_____ae______________series_60.part4.rar

http://rapidshare.com/files/18123842/1600_____ae______________series_60.part5.rar

Oke, Met download Guys ...

Database Skills: Second Normal Form

Desember 24, 2007 | | 0 komentar

The most basic skill that you need for successful
database projects is table design. Strong
table design leads directly to efficient and
clean code, while weak table design leads in the
opposite direction, code that is hard to write and
hard to maintain.

This essay is part of the Keys, Normalization and Denormalization series.
There is also a Complete Table of Contents and a >Skills-oriented Table Of Contents.

The Example

Our example is a school that has different kinds of
schedules on different days. Periods may be 35, 40,
or 45 minutes, and there may or may not be an assembly.
Our assignment is to create a page that displays the
periods for a day.

Nobody Argues About Second Normal Form

This week's essay is going to be rather short for
two reasons. The first reasons is that I have never
really heard anybody argue against second normal
form, and so there is no real debate for me
to review. In fact, from my own personal experience
I would say that Second Normal Form is possibly the least
controversial concept in computer science.

The second reason this essay will be short is that I
have no real-world examples of violations that
appear to make sense, so I have to make up the
example. Many people will put in repeating
groups (violating first normal form) and give you a
determined argument claiming they are doing the
Right Thing, but nobody
has done that to me with second normal form. So I had
to make something up to demonstrate what 2nd Normal
Form is.

Prelude: Multi-Column Primary Key

Before we get to second normal form we have to talk
very briefly about multi-column primary keys. A
multi-column primary key is exactly what it sounds
like, a primary key that has more than one column.

Our example from prior essays is a table of
periods with a primary key on
DAY_TYPE and PERIOD. No combination
of these columns can appear twice. So in the table
below the combinations in the first two columns
must be unique:


DAY_TYPE  |  PERIOD | SEQUENCE  |  START    |   END
----------+---------+-----------+-----------+----------
NORMAL    |  HOME   |   0       | 8:00 am   |  8:10 am
NORMAL    |  1      |   1       | 8:15 am   |  9:00 am
NORMAL    |  2      |   2       | 9:05 am   |  9:50 am

Second Normal Form

Second normal form is violated if you
have a column that depends on only a part
of the primary key. In this case it would mean a
column that depended only on DAY_TYPE or PERIOD.
This example has two
violations of second normal form:


DAY_TYPE  |  DAY_DESC     | PERIOD   | DESCRIPTION | SEQUENCE  |  START    |   END
----------+---------------+----------+-------------+-----------+-----------+----------
NORMAL    |  Normal       | HOME     | Homeroom    |  0        | 8:00 am   |  8:10 am
NORMAL    |  Normal       | 1        | Period 1    |  1        | 8:15 am   |  9:00 am
NORMAL    |  Normal       | 2        | Period 2    |  2        | 9:05 am   |  9:50 am   
...
...more rows for type NORMAL
...
ALONG     | Long Assembly | HOME     | Homeroom    |  0        | 8:00 am   |  8:10 am
ALONG     | Long Assembly | 1        | Period 1    |  1        | 8:15 am   |  9:00 am
ALONG     | Long Assembly | 2        | Period 2    |  2        | 9:05 am   |  9:50 am

Getting to Second Normal Form

In the example above the column DAY_DESC always has the same
value for a given value of DAY_TYPE. DAY_DESC depends
on only part of the key (which is DAY_TYPE + PERIOD),
and so it is a violation of second normal form.

The exact same error occurs with DESCRIPTION, which is
always the same for a given value of PERIOD. This value
depends on only part of the key, and so it is a violation
of second normal form.

The fix in both cases is to create parent tables to
hold these values. The primary key of the parent table
is one of the columns from the original table. Here
are the two tables we create when we normalize the
table from above:


DAY_TYPES:

DAY_TYPE          |   DESCRIPTION
------------------+--------------------------------
NORMAL            |   Normal Schedule 
ALONG             |   Long Assembly
ASHORT            |   Short Assembly
ALUNCH            |   Short Assembly After Lunch

PERIODS:
    
PERIOD       |   DESCRIPTION
-------------+-----------------------------
HR           |   Homeroom
1            |   Period 1
2            |   Period 2
3            |   Period 3
4            |   Period 4
LUNCH        |   Lunch
6            |   Period 6
7            |   Period 7
8            |   Period 8
ASSM         |   Assembly

Why Normalize?

Because this is a short essay this week, now
would be a good time to review the basic
reasons why we normalize.

In a normalized database, every distinct
fact is stored in exactly one location, and
each location stores exactly one fact (where
a "location" means the value of one column
in one particular row). This goal itself
serves the goal of avoiding something that
the database theorists call "anomalies".

In database terms, an "UPDATE anomaly" occurs
when you issue a reasonable update statement to
change something, but in fact the same information
is stored somewhere else as well, and your two
locations are now out of sync, your database has become
corrupted. An "INSERT anomaly" and a "DELETE anomaly"
are similar.

What this means to us programmers is that when
a database is not normalized we
end up with a significant burden
trying to keep the data correct. We waste a lot of
time fixing data on live systems (admit it,
you've done it!) or adding code trying to prevent
the problem. Many of those problems would be
avoided completely if the data were normalized.

Now, as always, programmer who do not know
databases well will argue that a system of
fewer tables is "simpler",
because he only needs one table instead of
three, and he does not need to use JOINs when
querying, or his ORM system is easier to write.
This may be true, but he now has the burden of
making sure that when an end-user changes
a description in one row that it gets changed in
all of the others. I personally would rather
spend my time adding a new feature then fixing
one I coded last year.

Normalization cannot solve all of your
problems, but it can very definitely solve
the ones it was meant to solve. If you can get each fact
stored in exactly one place then you never
have to waste time coding special fix-it
routines or crawling through inconsistent
data on a live system.

Conclusion: Easier Coding

Today we have seen another example of how
a normalized set of tables is actually
easier to work with than a so-called
"simpler" single table, because it is
easier to make sure that the data is
correct.

Tips & Tricks: Start-Up Options and Instances of ASP.Net Development Server in a Multi-project Solution

Desember 20, 2007 | | 0 komentar

If you have more than one project in your solution you can use following options of solution properties to set your start up actions... You can get the below dialog by right clicking your solution and going to its properties:

If you have more than one Web project (either Web Site, WAPs or both) in your solution and choose to start only one of it, you can do so by setting "Single startup project" above (or also via Project context menu "Set as StartUp Project" in solution explorer)... Although, even after doing so when you start debugging your application using ASP.Net Development Server you will see multiple instances of ASP.Net Development Servers in your system tray as shown below:

There is an important point to note here that a single instance of ASP.NET Development Server cannot handle more than one Web Application/Site... Ideally if you need this kind of functionality you should be using IIS for your debugging instead of ASP.NET Development server...

There are instances when you might have many web applications or web sites in the same solution and you may be actually debugging only one of them... In such scenario it might not be desirable to have multiple instances of ASP.NET Development Server running... VS provides an explicit setting in the property grid of web application/site called Development Web Server - "Always Start When Debugging" which is set to True by default... If you set this Property to be False only one web server instance will be created for the start up web project...

You might want note that in that same debug run, you will not be able to debug any other non-IIS based Web Application/Site in the solution who has this property set to "False"; but if you really want to debug just one application at a time you may not have to worry about it anyway...

Technorati Tags: ASP.Net Development Server,Cassini,Visual Studio,Debugging

Database Skills: First Normal Form

Desember 17, 2007 | | 0 komentar

Since all
non-trivial websites
require a database, and since database skills are
different from coding skills, there is very good
reason for any programmer to master the principles
of database design and use.

The most basic skill that you need for successful
database projects is table design. A strong
table design can be the foundation of a wonderful
application, while a weak design brings nothing but
delays, expense, headaches and heartaches.

One of the cornerstones of good table design is
the process of normalization.
Normalization proceeds through
different stages. The result of each stage is called
a "Normal form." So if we have completed the first
stage we say the database is in "First Normal Form",
and after we have completed the second stage we
say the database is in "Second Normal Form" and
so on.

This essay is part of the Keys, Normalization and Denormalization series.
There is also a Complete Table of Contents and a >Skills-oriented Table Of Contents.

The Example

Our example is a school that has different kinds of
schedules on different days. A normal day has 4 periods
in the morning, lunch, and then 3 afternoon periods.
Sometimes the periods are 35 minutes and there
is an assembly at the end of the day that goes to the
normal end of day. On short assembly days the periods
are 40 minutes each. There is a also a variation where
the short assembly might be after lunch instead of at
the end of the day.

A First Draft Table

Taking a stab at some table design, we may say
something like, "Well I can see that there are never
more than nine periods, and there are four kinds of
schedules. I can make a table that lists the four
kinds of schedules and tells me what happens in
each period, something like this:"


DAY_TYPE   | MINUTES | P0   P1   P2   P3   P4   P5   P6   P7  P8   
-----------+---------+----+----+----+----+----+----+----+----+----
NORMAL     | 45      | C  | C  |  C | C  | L  | C  | C  | C  | X 
ALONG      | 35      | C  | C  |  C | C  | L  | C  | C  | C  | A 
ASHORT     | 40      | C  | C  |  C | C  | L  | C  | C  | C  | A 
ALUNCH     | 40      | C  | C  |  C | C  | L  | A  | C  | C  | C

....where "C" means a class period, "L" means lunch,
"A" means assembly and "X" means nothing happens.

It so happens that this table is not in first normal form.
We will look at what this means
first in theory, and then we will see the practical problems
that come from it.

First Normal Form as Theory

A table is in first normal form if it has
no repeating groups.
The example above repeats the period column
nine times with columns P0, P1, P2.
This is a repeating group, and so it
violates first normal form. Theory tells us that
we must redesign the table, splitting the repeating
group out into a child table. This will leave
us with two tables, one that is for
day types and the other that tells us about periods.
The table of day types is now quite simpler:


DAY_TYPE   | MINUTES | DESCRIPTION
-----------+---------+-----------------------------                  
NORMAL     | 45      | Normal Day                            
ALONG      | 35      | Long Assembly
ASHORT     | 40      | Short Assembly                           
ALUNCH     | 40      | Short Assembly After Lunch

The original table had ordering information
buried in the names of the columns. We need to
have that same information in our child table
so we will have the PERIOD column be numeric and
it will determine the order of the periods.
Here is the table with some of
its entries:


DAY_TYPE   |  PERIOD   |   ACTIVITY 
-----------+-----------+---------------
NORMAL     |  1        | Class
NORMAL     |  2        | Class
NORMAL     |  3        | Class
NORMAL     |  4        | Class
NORMAL     |  5        | Lunch 
NORMAL     |  6        | Class
NORMAL     |  7        | Class
NORMAL     |  8        | Class
ALONG      |  1        | Class
ALONG      |  2        | Class
ALONG      |  3        | Class
ALONG      |  4        | Class
ALONG      |  5        | Lunch 
ALONG      |  6        | Class
ALONG      |  7        | Class
ALONG      |  8        | Class
ALONG      |  9        | Assembly

We have now satisfied the theory, and put
our fledgling database into First Normal Form.
But the question arises, wasn't the single-table
version a lot simpler? This new "fixed" version seems more
complicated. A programmer might say something
like, "I have to look all over the place to find
what I need." To answer these objections we will
now examine the practical side of the example.

Problem 1: Structure Changes

The non-normalized example is probably fine if you have
just one school that never changes their schedule. But if
you have multiple schools you will need to change your
structure for them, adding or removing periods.

To this we might reply, "but sure, structures change
all of the time." Yes, it is true that a structure change
may be required
to improve a program or add functionality, but in the
example above you must change the structure
in cases where you are not improving the program or
adding functionality. This means the more people use
your program, the more work for you! By contrast,
in the normalized situation a different schedule just
means an end-user task to make entries in the tables.

You can argue that this particular
example is not so bad, because, after all, how many
periods can any school really have? Let's make a table
with 15 periods and be done with it, no? The problem is that
if you win that argument and make a habit out of
repeating groups then you saddle your development efforts with
the ongoing need to do structure changes where simple
data editing would have done the job.

Problem 2: Secondary Columns

I worked on a system one time that had a repeating group
of 24 columns in several tables. The columns were for the size of an
item of clothing. In one table there were 24 additional
columns for price. Then 24 more for cost. Then 24 more
for gross profit. There were more, should I continue?

The problem would appear in our school schedule if we
wanted to put the start and end times of the periods into
the tables so we did not have to figure them out on
every page load. We would now have START0, START1, END0, END1, and
so on, eighteen more columns. Such fat tables like this are
very clumsy to work with both in code and when doing ad-hoc
queries.

Problem 3: Constants Required

Imagine you have a simple routine called SQL_ALLROWS()
that gives you query results in an array (if you don' have
one, code it today!). If your database is well normalized
your code will display this pattern a lot:


$rows = SQL_AllRows(
    "SELECT activity FROM period_info 
      WHERE day_type = 'NORMAL'
      ORDER BY sequence"
);
foreach($rows as $row) {
   // ...do something interesting...
}

This simple code is not possible when you violate first
normal form. You must put a constant into your
code somewhere so that your code knows how many columns
there are. This is an extra bit of maitenance to worry
about here:


$row = SQL_OneRow(
    "SELECT * FROM period_info 
      WHERE day_type = 'NORMAL'
);
for($x = 0; $x < NUM_PERIODS; $x++ ) {
   $period = $row['P'.$x];
   // ... do some display...
}

Problem 4: Query Construction

For problem 3 above, I put a "Select *" into the
query. I really should not
have done that. I should have listed all 9 "P" columnns
(or all 27 columns if we put start and end times
in also). Something like this:


SELECT P0,P1,P2,....

But this violates good programming practice. If the structure
changes then I have to go to all of those queries and
modify them. A better programming practice would be
to use that NUM_PERIODs constant to generate column lists
on the fly:


$cols = array();
for ($x = 0; $x < NUM_PERIODS; $x++ ) {
  $cols[] = 'P'.$x;
}
$query = "SELECT ".implode(',',$cols)." from...";

Most programmers will avoid a bit of code like this because
it seems at first glance to be really stretching a point.
Of course once the program is successful and the additions
and changes come in that
leaves you going through and changing every query
every time you modify the structure. None of this is
necessary with the normalized version.

It is starting to seem like a stretch to claim that
we have take the simpler path here. Perhaps the
"complicated" normalized tables really are simpler.

Problem 5: Hard-Coded Tools

As I write this in December of 2007 the web is
rediscovering a UI widget that has been in use for
decades in terminals and desktops: the grid. The grid
is the natural method of editing child tables in
admin interfaces.

Before 1995, when there were no web programmers,
a programmer who violated first normal form paid the
price by needing to code up things like grids by
hand because he could not use grid-like tools available
in his framework. The modern web programmer will
pay the price in not being able to use the grids
that are rapidly coming online.

Problem 6: Cannot Aggregate

Finally we will consider a simple question, tell me
how many periods there are in any particular DAY_TYPE.
In a normalized database the SQL is easy:


SELECT COUNT(*) FROM periods WHERE day_type='NORMAL'
-- or, to get them all:
SELECT COUNT(*),Day_type
  FROM periods
 GROUP BY day_type

Getting the same answer in the non-normalized database
requires code. It does not matter how simple that
code is, the fact is that if the tables were
normalized the code would not be required at all. Multiply
that by 10 tables, 100 tables, and you just have
complication after complication.

Conclusion

Violating first normal form puts us in a situation where we
need programmers to make changes, while normalized databases
can be modified by end users. Violating first normal
form also forces us to embed and maintaint constants we would
not otherwise need and to change queries that could
otherwise be left alone. These problems can be mitigated with
libraries of code that build queries for us, but still those
libraries have to be written.

In this light, we see can see first normal form as something that
creates efficient code and easier-to-maintain
databases.

Database Skills: Complete Contents

Desember 17, 2007 | | 0 komentar

This posting is updated whenever a new post goes up.

There is a also a
>Skills-oriented Table Of Contents. It is not as complete as this list,
which lists all posts, but it is more centered on links as they relate to skills.

If you want some free analysis, why not >submit your schema to the
Database Programmer? If you are willing to discuss your issues with a bit of public
exposure, I will provide free analysis, and everybody can benefit!

>User-Submitted Analysis Topic: Email

The Application Stack

Table Design Basics: Keys, Normalization, Denormalization

The first group of posts introduces the must-know terms and techniques for table design.

It might be a good idea to start with
>The Relational Model.

>Introduction (spell it out or figure it out)
>Primary Keys
>Foreign Keys
>First Normal Form
>Second Normal Form
href="http://database-programmer.blogspot.com/2008/01/database-skills-third-normal-form-and.html"
>Third Normal Form and Calculated Values
"http://database-programmer.blogspot.com/2008/03/of-tables-and-constraints.html"
>Of Tables and Constraints (also listed below in Table Design Patterns)

Following up on the normal forms are some basic discussions of
normalization and denormalization.

Table Design Patterns

The second subseries details commonly occurring patterns in table design,
how to recognize them and when to use them.

There is a complete "http://database-programmer.blogspot.com/2008/01/table-design-patterns.html"
>List of Table Design Patterns. The rest of the entries are:

SQL SELECT and Queries

Algorithms and Processes

"http://database-programmer.blogspot.com/2008/08/advanced-algorithm-sequencing.html"
>Sequencing Dependencies

Server-Side Code

Analysis

Development Cycle

Philosophy

Data Dictionary

Many of these posts are listed elsewhere in this table of contents,
but I wanted to have them altogether in one place as well.

Security

Performance

The Browser

Edit & Continue feature for Web Application Projects (WAPs)

Desember 12, 2007 | | 0 komentar

There is Edit & Continue functionality available for WAPs... Although we have disabled it by default as it may potentially have debug performance impact due to the fact that we have to recycle the ASP.NEt Web Server process every time for this functionality to work...

Although I think the performance hit is not as big to let go of not using the feature... I would recommend that you go and try it out by checking the Edit & Continue checkbox in your Web section of Property Pages as below:

But also do note that this property in addition to your tools options Edit & Continue should be checked otherwise the feature won't work...

Also note that if you are in web development profile you will have to check "Show all settings" in the bottom of the Tools--> Options windows within Visual Studio...

Technorati Tags: Visual Studio,ASP.Net,WAP,Debugging

Workaround: Debugging Global.aspx.cs with ASP.Net Web Server within Visual Studio

Desember 12, 2007 | | 0 komentar

When you add a global.asax file to your "Web Application Projects (WAPs like below:

and then write code in Application_Start event and try to debug it like below using Visual Studio inbuilt Web Server

Then during your first debug the breakpoint is hit but during your subsequent debug runs the breakpoint is not hit.

The reason behind this is that we do not kill the ASP.Net Web Server process after your every debug run and hence Application_Start() is not fired every time. There is a good reason why we do so... Starting ASP.Net Web Server process is an expensive task and in most of the scenarios recycling this process after every debug would adversely impact your performance... If you do not want to debug your Application_Start() method then probably you do not need to have the process restart and save performance most of the time...

However if you would like to have the breakpoint hit you have few easy workarounds... One of the workaround is that you stop the web server from your system tray as in the figure below:

Alternatively you can go to your property pages of your web application and enable Edit & Continue like shown below:

When you choose Edit and Continue then we recycle the ASP.Net Web Server process on every debug run (it is needed for the Edit & Continue functionality to work)... This way although you will see very marginal degrade in your performance you will still be able to debug your Application_Start() methods...

Hope this helps...

Our team Visual Web Developer is hiring...

Desember 12, 2007 | | 0 komentar

The Visual Web Developer team is looking for a few talented and experienced invididuals to join our team. We have opportunities in development, testing, and program management. Our team builds Visual Studio features that enable creating applications for ASP.NET, IIS, Silverlight and Sharepoint.

Here are links to our current openings:

To submit your interest in any of these positions, please email -- vijoshi-at-microsoft-dot-com -- with an attached resume.

Database Skills: Foreign Keys

Desember 10, 2007 | | 0 komentar

This is the third in a series of articles that
will help you develop your database skills,
Since all
non-trivial websites
require a database, and since database skills are
different from coding skills, there is very good
reason for any programmer to master the principles
of database design and use.

This essay is part of the Keys, Normalization and Denormalization series.
There is also a Complete Table of Contents and a >Skills-oriented Table Of Contents.

The Example

This week the example continues from the last two weeks.
A school
has 8 periods in a day that are varying lengths, sometimes
an assembly, and of course homeroom. Our assignment is
to code a screen that shows the begin and end times of
each period depending on what schedule was being followed
for the day. We have already decided to "spell it out"
by populating a table with the start and end times for
each period in each kind of day (the schedule was
described in the first essay in the series.
Here is a list of about half of the rows in the table:


DAY_TYPE  |  PERIOD | SEQUENCE  |  START    |   END
----------+---------+-----------+-----------+----------
NORMAL    |  HOME   |   0       | 8:00 am   |  8:10 am
NORMAL    |  1      |   1       | 8:15 am   |  9:00 am
NORMAL    |  2      |   2       | 9:05 am   |  9:50 am   
NORMAL    |  3      |   3       | 9:55 am   |  10:40 am
NORMAL    |  4      |   4       | 10:45 am  |  11:30 pm
NORMAL    |  LUNCH  |   5       | 11:35 pm  |  12:20 pm
NORMAL    |  6      |   6       | 12:25 pm  |  1:10 pm
NORMAL    |  7      |   7       | 1:15 pm   |  2:00 pm
NORMAL    |  8      |   8       | 2:05 pm   |  2:50 pm
ALONG     |  HOME   |   0       | 8:00 am   |  8:10 am
ALONG     |  1      |   1       | 8:15 am   |  8:50 am
ALONG     |  2      |   2       | 8:55 am   |  9:30 am
ALONG     |  3      |   3       | 9:35 am   |  10:10 am
ALONG     |  4      |   4       | 10:15am   |  10:50 am
ALONG     |  LUNCH  |   5       | 10:55 am  |  11:30 am
ALONG     |  6      |   6       | 11:35 am  |  12:10 pm
ALONG     |  7      |   7       | 12:15 pm  |  12:50 pm
ALONG     |  8      |   8       | 12:55 pm  |  1:30 pm
ALONG     |  ASMB   |   9       | 1:35 pm   |  2:50 pm
....
.... same for other two schedules
....

Now we will see how a foreign key will help to
make sure the above table is correct.

The Foreign Key

A foreign key is used to prevent certain kinds of
errors.
In our example above we see that the column DAY_TYPE has
only two values, NORMAL and ALONG (and ASHORT and ALUNCH that
were not dipslayed). If a user were
typing in this schedule and accidentally typed 'NRMAL'
or 'NORMALL' we want to catch that and prevent it. A
foreign key is how we do this. Making the column
SCHEDULE_TYPE a foreign key means here is some other
table that holds the allowed values. We call that other table
the parent table. Such tables are also called lookup
tables, reference tables and sometimes leaf tables.
Here is the parent table of SCHEDULE_TYPES, which lists
the allowed values of SCHEDULE_TYPE.


SCHEDULE_TYPE     |   DESCRIPTION
------------------+--------------------------------
NORMAL            |   Normal Schedule 
ALONG             |   Long Assembly
ASHORT            |   Short Assembly
ALUNCH            |   Short Assembly After Lunch

The column PERIOD will also be a foreign key, and
the parent table will look like this:


PERIOD       |   DESCRIPTION
-------------+-----------------------------
HR           |   Homeroom
1            |   Period 1
2            |   Period 2
3            |   Period 3
4            |   Period 4
LUNCH        |   Lunch
6            |   Period 6
7            |   Period 7
8            |   Period 8
ASSM         |   Assembly

Database people say that a foreign key enforces
"referential integrity". This term comes from the
fact that one column reference another, and this
reference ensures the integrity of the data.

The SQL Code

This SQL is illustrative only. Your particular
database may require additional commands or
syntactical variations.

Creating the two lookup tables is accomplished like so:


CREATE TABLE periods (
     PERIOD char(8)
    ,DESCRIPTION char(25)
    ,PRIMARY KEY (PERIOD)
)
CREATE TABLE day_types (
     DAY_TYPE char(8)
    ,DESCRIPTION char(25)
    ,PRIMARY KEY (DAY_TYPE) 
)

The table of actual periods for each kind of day
is created with the code below. I have used type
'character' for the start and end times to keep things
simple for now.
Note the two foreign keys, one to each table:


CREATE TABLE periods_x_days (
     DAY_TYPE char(8)
    ,PERIOD char(8)
    ,SEQUENCE int
    ,START char(8)
    ,END char(8)
    ,PRIMARY KEY (DAY_TYPE,PERIOD)
    ,FOREIGN KEY (PERIOD) REFERENCES PERIODS(period)
    ,FOREIGN KEY (DAY_TYPE) REFERENCES DAY_TYPES(DAY_TYPE)
)

There is a multiple-column primary key that
I snuck in there. By enforcing a primary key
on DAY_TYPE and PERIOD, we make sure that there
is no accidental double listing for a particular
type-period combination.

The Basic Building Blocks

Now that we know how a foreign key works and
what it does, we can start to talk about why
it is important. In short, the foreign key
connects your tables together so that you have
a true database. Without the foreign key all
you have is a jumbled bag of unrelated tables.

An analogy to code may be in order here. Most of
us can list many ways in which bits of code can
connect to each other. You can call a function,
you can make complex objects via composition,
you can make classes via inheritance, along with
many others. All of these mechanisms tie bits of
code together into a coherent application. The
corresponding fundamental way to tie tables together
in a database is the foreign key.

So to sum it up, we have seen so far that:

A database programmer by inclination wants to
spell everything out in tables.
Each table stores information about exactly
one kind of thing, and a primary key makes
sure there are no duplications.
Foreign keys define how different kinds of
things relate to each other.

The Server Does The Work

Using a foreign key is a good way towards moving
your business logic into the database server
itself. Once you have defined the foreign
keys above, the server will never allow you
(or your users) to accidentally or maliciously
insert bad data. This command:


INSERT INTO periods_x_days (
    day_type,period,sequence,start,end
)
values (
   'FICTION','99',5,'11:00 pm','11:05 pm'
)

...will throw an error when you try to execute it. The
exact wording varies from product to product, but the
bottom line is you are fully protected from these errors
without doing any coding of your own.

Foreign Keys and The Classic Blunder

Last week we noted that many programmers have the
idea that they can combine the PERIODS table and
the DAY_TYPES table into a single table, thereby
"saving" a table. I did my best to debunk this idea
by pointing out that

First, it is actually less efficient
to do so because it complicates code and requires
at least one extra colum, and
Second, it destroys the value of the
primary key column as a unique identifier of a
single kind of thing.

We now have a third argument, based on our understanding
of the foreign key. If we combine the tables then
we can no longer use the combined table as
a lookup table for foreign keys. The classic
blunder of "saving a table" means the resulting table
cannot be tied properly to anything else.

This kills the idea off completely,
since the entire purpose of creating the tables
is to use them as parent tables for foreign keys!

Conclusion: The Building Blocks

When we grind out code, we do not usually expect
the customer to give us rigorous specs. They
tell us what they need in their own language and
we have to convert those needs into functioning
code. We use building blocks like classes,
functions, conditionals and iterators to
make those programs.

Designing a database is the same as designing
code insofar as the customer will not be
able to design it for you. They will be able
to tell you want they want in their own
language, but you will have to design the
tables. That process of table design is
all about identifying primary and foreign
keys. Next week we will begin to see how
to do this, through the process of
normalization.

ASP.Net 3.5 Extensions just released

Desember 09, 2007 | | 0 komentar

We just released ASP.Net 3.5 Extensions on Microsoft Download Center... This release includes preview of following technologies:

ASP.NET MVC
ASP.NET Dynamic Data
Silverlight controls for ASP.NET
ADO.NET Data Services
Entity Framework runtime, and
New features for ASP.NET AJAX.

You can download ASP.Net 3.5 Extensions from below:

http://www.microsoft.com/downloads/details.aspx?FamilyId=A9C6BC06-B894-4B11-8300-35BD2F8FC908&displaylang=en

I will blog about many of these technologies in time to come...
you can also find more interesting links on the release on Brad Abrams blog @ http://blogs.msdn.com/brada/archive/2007/12/09/the-wait-is-over-asp-net-3-5-extensions-preview-posted.aspx

PDC 2008 is announced

Desember 06, 2007 | | 0 komentar

Technorati Tags: PDC 2008,Professional Developer Conference,Microsoft Events

PDC which was earlier slotted for Oct 2007 was moved to Oct 2008 and is planned in LA Convention Center from Oct 27th to Oct 30th 2008... More information can be found below:

http://msdn2.microsoft.com/en-us/events/bb288534.aspx

Database Skills: Primary Keys

Desember 03, 2007 | | 0 komentar

This is the second in a series of articles that
will help you develop your database skills,
Since all
non-trivial websites
require a database, and since database skills are
different from coding skills, there is very good
reason for any programmer to master the principles
of database design and use.

This essay is part of the Keys, Normalization and Denormalization series.
There is also a Complete Table of Contents and a >Skills-oriented Table Of Contents.

The Example

This week the example continues from last week. A school
has 8 periods in a day that are varying lengths, sometimes
an assembly, and of course homeroom. Our assignment is
to code a screen that shows the begin and end times of
each period depending on what schedule was being followed
for the day.

Last week we introduced the idea that the
database programmer will tend towards trying to
spell it out. That is to say, the database programmer
will cast the solution in terms of saving information in
a database that can be retrieved later on. He will
generally avoid coding an algorithm that "figures it out"
if he has the chance to simply store data that can be
retrieved as needed. We will now see how a primary key
works by looking at two tables that make up part of the
solution.

The Primary Key Defined

The primary key is pretty easy to understand. It is
simply the column or columns in a table that must be unique.
In our example of the school schedule the database
programmer is going to create two reference tables that
have single-column primary keys and just a few
rows each. Here they are, the table of
schedule types and the table of periods:


SCHEDULE_TYPE     |   DESCRIPTION
------------------+--------------------------------
NORMAL            |   Normal Schedule 
ALONG             |   Long Assembly
ASHORT            |   Short Assembly
ALUNCH            |   Short Assembly After Lunch


PERIOD       |   DESCRIPTION
-------------+-----------------------------
HR           |   Homeroom
1            |   Period 1
2            |   Period 2
3            |   Period 3
4            |   Period 4
LUNCH        |   Lunch
6            |   Period 6
7            |   Period 7
8            |   Period 8
ASSM         |   Assembly

The first table has a primary key of SCHEDULE_TYPE.
No two rows in that table can have the same value
of SCHEDULE_TYPE. The second table has a primry
key of PERIOD, so that no two rows in that table
can have the same value of PERIOD.

A primary key is in fact very simple and does not
really require a lot of discussion except for one
further point: a primary key identifies something.
For example, the value 'NORMAL' identifies a certain kind
of schedule, and if I am given this value I can look
up things about the schedule in the SCHEDULE_TYPES
table.

Detour: Code and Data Decisions

These examples are so far very simple, so it may not
be obvious that the tables SCHEDULE_TYPES and
PERIODS are really necessary. After all, we can
just put them into an associative array in
some type of include file and
not bother making tables, right?

Technically, you can of course put anything you
want into an include file and save yourself some
time at the front of a project. The drawbacks
emerge over time and are the consequence of
"trapping" data inside of code.

The first and most obvious
drawback is that if the customer wants to change
a description then a programmer must change a
program file, instead of just having a user go to
an admin screen. But worse, what if our program
becomes a smash hit and schools all over the country
are using it? What if they all want different
descriptions, or what if they have different numbers
of periods and kinds of schedules?
If we start off by putting such things
into tables then we will be well prepared for
future demands, but if we "trap" the data in
code then future success will produce choking
demands on the programmers to change the files.

If the tables were more complicated we would have
another issue. Databases were designed for
efficient querying, but arrays were not. Querying
the data that is trapped in code is much harder
than querying tables in the database.

So we will take it as a given that data belongs
in a database, even for simple two-column tables.

The Primary Key And a Classic Blunder

Programmers are by nature visual thinkers and we
tend to be good at pattern recognition. This is why
it is so common for programmers to look at the
example above and say, "Hey! I just noticed that both
of those tables have the same structure, a code
and a description! I've got a great idea, I'm going
to combine them into one table, which will be more
efficient!"

This is a classic blunder. It is a result of
applying wisdom from one situation into a different
situation where that wisdom does not apply.
Here is what happens. The
programmer takes his idea of efficiency, which he
learned from writing code, and tries to apply it to table
design, which operates on completely different
principles. He thinks that by replacing two
tables with one he is being more efficient, but the
real result is less efficiency.

First off, the new combined table now requires a
new column, ROW_TYPE, which was not necessary
before. More complicated, less efficient.

Secondly, a simple query to pull all types
of schedules now requires a filter on ROW_TYPE that was
not required before. This raises major alarms for
seasoned programmers because any time you make a
simple action more complicated with no apparent
gain then you are on a bad road!

But most importantly for today's
essay, the "efficient" single-table approach
has muddled the primary key.
The value 'ASHORT' by itself no
longer uniquely identifies a schedule type. To
solve this we end up in strange discussions. Should
the column ROW_TYPE be part of the primary key?
Or should we keep the single column key and have
the odd situation that
a schedule type and a period cannot have
the same code? These conversations should raise
alarms with any seasoned programmer because we
have barely gotten started with two simple
tables and already we are struggling with the
very basics of picking primary keys!
Even a programmer with
no database experience should be suspicious of an
approach that requires wrangling with the very
basics. What good can come of that? The big irony is
that these complications arose from the
"simplification" of combining two tables into one.

Finally, there is a big technical problem with
foreign keys and the one-table approach, but that
can wait until next week.

All of these problems can be avoided by remembering
that each table in a database contains information
about one kind of thing and only one kind of thing.
The primary key is
that column or columns that uniquely identifies
each of these individual things.

Conclusion: Look for the Keys

The primary key is simple to understand.
It is a column or columns that must
be unique in a table. But beyond that, the primary
key is not just unique values, but unique values
for like items. Database design skills begin with
identifying the kinds of things that must be
tracked, putting each into a table, and assigning
the primary keys to those tables.

Web Deployment Projects for VS 2008 Dec 07 CTP Released

Desember 01, 2007 | | 0 komentar

Today after more than two months of effort our team released the Dec 07 CTP of Web Deployment Projects (WDP)... We were receiving one or more requests nearly every week since last few months to have WDP out for Orcas so I am sure that this release will enable a tons of web developers to adopt VS 2008 and use the latest and greatest features that come along with...

I have created a blog post on our team blog which talks more about this release... You can click here to view the post (http://blogs.msdn.com/webdevtools/archive/2007/12/01/web-deployment-projects-wdp-for-visual-studio-2008-december-2007-ctp-released.aspx)...

I want to mention that we have a great team in Visual Studio Web Developer... Honestly, the team rocks, often time we never know who make these technologies happen and so to name a few those people are Wendy Wei, Alison Lu, John Dundon, Tim McBride, Bill Hiebert, Anna Lidman, Bradley Millington, Bradley Bartz, Omar Khan and others... Hope you enjoy the release...

I will keep posting other tips and tricks around WDP on this blog in the weeks to come so do visit once in a while...

The Example

Nobody Argues About Second Normal Form

Prelude: Multi-Column Primary Key

Second Normal Form

Getting to Second Normal Form

Why Normalize?

Conclusion: Easier Coding

Other Posts

The Example

A First Draft Table

First Normal Form as Theory

Problem 1: Structure Changes

Problem 2: Secondary Columns

Problem 3: Constants Required

Problem 4: Query Construction

Problem 5: Hard-Coded Tools

Problem 6: Cannot Aggregate

Conclusion

Other Posts

The Application Stack

Table Design Basics: Keys, Normalization, Denormalization

Table Design Patterns

SQL SELECT and Queries

Algorithms and Processes

Server-Side Code

Analysis

Development Cycle

Philosophy

Data Dictionary

Security

Performance

The Browser

The Example

The Foreign Key

The SQL Code

The Basic Building Blocks

The Server Does The Work

Foreign Keys and The Classic Blunder

Conclusion: The Building Blocks

Other Posts

The Example

The Primary Key Defined

Detour: Code and Data Decisions

The Primary Key And a Classic Blunder

Conclusion: Look for the Keys

Other Posts

Tawk.to

Pencarian

Blog

Populer

Populer

My Ads

Artikel

Artikel