Download MORE ABOUT COLUMN DATA AND OTHER PROPERTIES

MORE ABOUT COLUMN DATA AND OTHER PROPERTIES
In this video, we will expand on several of the ideas presented about columns in the previous
lesson, talking specifically about data types and other properties that allow you to define
columns that enforce a high degree of integrity, and therefore, usability of your data.
In the previous lesson, we said that tables are comprised of one or more columns, and that
columns are made up of three basic ingredients. First of all, a column is going to have name.
It is going to have a data type, and then there might be some other properties that are
associated with that given column. And this is not an exhaustive list by any stretch of
imagination, but these are probably some of the more common ones. We have already talked
briefly about whether or not this particular field of information can have an automatic
numbering sequence. Obviously, this would be applicable to those numeric fields, and we
will show in this video later on how to set an identity column. We have already looked at
whether or not a field can be empty or not by setting the nullable property for a given field.
We have not really covered this yet, but in this particular column that we are working with a
key field in relating the table to other tables. And so, we can set a property that basically
designates this as a primary key or whether it uses a foreign key. And then also there are
properties that allow us to define default values so that as a new row of information is being
inserted into a table, so a new record is being created, a particular field of information, if not
specified can default to a certain value, and again that is something that can be dictated by the
definition of the properties for that given column.
[Start: 00:00:00 End 00:01:43]
Then you might be asking why do we need to go through all this effort to adorn our columns
with all this extra information. Are these extra properties really worth all the learning curve
that we have to put into really understanding what they do and how they affect the design of
our tables? And the emphatic answer is absolutely. Not only are they important, but they are
really an integral part of creating a usable data store for our data. Now, in most cases, they
not only enforce integrity, but honestly, they can make things much easier than say, trying to
accomplish the same source of results purely with Visual Basic or C# code.
More
importantly, employing some of the special properties columns reduces the headaches that
you encounter down the line as your application expands and grows to your need, because
after all, a good data store is not worth anything if the data inside of it is worthless. And the
data type as well as the other properties give you the tools to maintain a high degree of
integrity to ensure that your data is meaningful and useful for the purpose of its design. So,
how exactly is that integrity enforced to the use of data types and column properties? I have
got a couple of ways listed on this slide. For example, ensuring that the data is of the correct
data type, means that no longer will people be able to put random values into their
applications to store currency data or to store datetime data. Invalid entries are eliminated by
specifying the data type that can be stored in the database because you do not want
information to be input improperly or else the reporting on that data becomes impossible. It is
also important that some information is not allowed to be left blank.
There is certain
information that you have to find upfront that has to be there before we can save a record of
data into the database, or else, that row of data is virtually useless if we do not have a first
name and the last name for a customer, for example.
[Start: 00:01:43 End 00:04:00]
Similar to some of the other points that we made earlier, just making sure that the data falls
within appropriate range of values that are expected. We do not want to have currency values
input for date values and vice versa. As with the dates we did in the previous lesson, we are
not trying to end our dates from something like the third century. But, rather we are storing
meaningful dates for events and things that have recurred at this point in time. So, defining
some of this does not solve all your problems. You are still going to have some issues of the
accuracy of data. However, as much as it is possible by using some of these tools, your data
becomes more reliable than say if, it had been stored in a simple flat text file, a flat database, a
structure, or an Excel spread sheet, or whatever the case may be.
So, we are talking about restricting the kind of data that can be inserted and updated within
our databases, conceptionally, we are talking about constraining the data or placing
constraints on our table. And a constraint is simply anything that we do to the definition of
the a table’s columns that in some way restricts what is allowed to be input into the table’s
rows in any way.
There are several ways that we can enforce data integrity through the use of constraints. A
data type is a type of constraint. When we talk about relating tables to each other that is a
special type of constraint called referential integrity. We will talk about that in the next video.
There are other special rules that we can place on columns such as special constraints that
would allow us to perform more complex operations like looking up and seeing if other
values are present before it allows an insertion of data. These kinds of programmatic checks
and constraints can be implemented through SQL Server.
[Start: 00:04:00 End 00:06:08]
That is a little bit more advanced. I am not going to cover this topic in this particular video
series though.
But, I think, really the gist of this particular slide and the lesson up to this
point is that even though we usually think of constraints as a bad thing—that a restriction is a
bad thing--it is actually one of the best friends that we have as developers and administrators
of databases because it eliminates some of the possible badness that can happen within our
applications whenever bad data happens or when somebody tries to input bad data into our
database. We can stop it, and not allow it, and continue to make our applications useful and
less prone to errors.
Okay, so now that you are onboard with the user constraints and you love the concept of using
data types because that really makes your database more useful in the long run, the inevitable
question with so many options available to you in terms of data types to use when defining
your columns is this: How do I learn what all these data types are? There are just so many of
them to choose from. My suggestion to you is to really just get to understand and get familiar
with some basic data types and then grow your collection and your knowledge of data types
from there. Similar to how you did it when you learned Visual Basic or C#, for example.
So, as a rule of thumb, you can generally use the INT or integers for big numbers. And we
are talking really big numbers in the millions and millions. Integers, in fact, cannot have
decimal points, they have to be whole numbers. If you need small numbers in the interest of
keeping the size of the data or the footprint of the data on your physical disk drive as small as
possible, we would want to use tinyint or smallint for smaller numbers where we only need
hundreds or thousands instead of millions and so on. If we’re expecting a lot of text, we can
use a varchar. If you are expecting a lot of text, we can then use the varchar(max).
[Start: 00:06:08 End 00:08:29]
So, in the previous lesson, you saw how we defined varchar(50), 50 being the length of that
given field. So, the maximum size of that field can be 50 characters in length, but it expands
and contracts to really accommodate the amount of characters that we are going to place in
there up to an absolute limit of 50. Well, if we needed a lot of text, maybe like paragraphs of
text, we do not really know how much data we are really expecting there. Then in some rare
situations, we can use varchar(max), which will allow us to put just as much information, as
much textual information such as paragraphs and pages of data inside of that particular field
of data.
Now, if we have a need for any special characters, such as other character sets like Japanese
or Chinese or whatever the case might be, you can use the nvarchar, which is equivalent to
varchar such that it allows for unicode characters. In most cases, a smalldatetime field will
suffice for your date and time needs. What is the difference between smalldatetime and
datetime? Simply put, sometimes you just do not need fractions of a second. So, you do not
need the daytime field. Small daytime excludes fractions of a second. Therefore, it is not
useful in most cases. Again, if you need some type of currency to be saved, smallmoney will
suffice. The regular money will allow for more spaces after the decimal place, larger sums of
cash, smallmoney works in most instances for your typical transaction sizes. And then if you
just have a simple field of information where you need to store on or off, yes or no, the bit
data type will suffice for that. It will save as a 0 or 1.
[Start: 00:08:29 End 00:10:27]
Now, if you are in doubt, take some time and go through the SQL Server help files, and look
up data types and review what values, what range of values can fit in each of these and the
other data types that are available to you.
Because selecting the right data type is so
important. And so, that is why I inserted this slide because I want to impress upon you why it
is important to select the proper data type for your application. We could go through and
define everything as varchar(50). But, having gone through a review of why data types are so
important, you can strain the data to make it more useful. It’s important to really focus on the
task of researching and making sure that we are using the right data types for applications. If
we select the data type that allows too much information more than our application would
need, then we are wasting space, and usually that is not a large issue for us nowadays in
smaller applications, but for very large applications, at more of an enterprise scale, selecting
the right data type is crucial. Selecting the wrong data type could cause our company
thousands of, not hundreds of thousands of dollars. Now, if you select too small of a data
type, then you put in an artificial ceiling on what our application is able to accept. So, we
certainly do not want to do that either. If we select the wrong data type, then getting the data
into and out of the database becomes a very time consuming and frustrating process. We have
to convert the data type to the correct data type for use in our reports, in our applications, and
then convert it back for storage back into the database. From personal experience, this can
often be a very painful process, so, selecting the right type reduces the amount of data
conversion that we need to do in and out of our data store.
[Start: 00:10:27 End 00:12:35]
It also makes, as I have just kind of alluded to, reporting more difficult, especially in regards
to some of the functions that we can perform on the data. Let me give you a couple of
examples where you can see selecting the right and wrong data types can make a difference.
Say, for example, a ZIP code. Now, in the United States, we have either five numbers or it is
nine numbers that can represent a ZIP code. They are all numeric values and we can expect it
to be that five or nine. So, our first thought might be to use numeric columns, maybe, a
smallint, or just a regular integer value. But, those are really reserved for those times
whenever you need to perform some type of aggregation of the data say if we needed to get a
sum of all of the given columns and you add up all the numbers or we need to perform some
mathematical equation on the data, or represent a true value as opposed to just a designation,
which is really all the ZIP code and the postal code is. We also need to keep in mind that in
other countries, that ZIP code or rather the postal code can be more than five or nine
characters and that they often include alphanumeric characters. So, for example, in Canada, it
is alphanumeric. Then defining ZIP code as an integer or small INT really places an artificial
ceiling on our application, not allowing people from other countries to interact with our
application.
[Start: 00:12:35 End 00:14:25]
Similarly, we could store our money values as integers, but in doing so, we will only be able
to store whole numbers, we would not be able to store any values after the decimal place.
Now, in some applications, that might make sense, however, I think, it is always a good idea
to either use money or smallmoney in our applications. Okay, as we finish up this lesson,
let’s talk about the importance of the identity column. We first noted the identity column in
the previous lesson, and now it is time to go back to that example, and modify one of the
columns that we defined for our customers table to make it an identity column. But, what is
an identity column? Well, it is basically a special property that allows us to define one
column that will automatically increment or decrement based on our settings so that we can
get a unique value in each row of that given table. Now, why we do that might not be so
obvious in this lesson. In the next lesson, it is going to become very obvious when we begin
to talk about primary foreign key relationships between tables. But, since we are on the topic
of adorning our columns with properties, I felt like it was really a good idea to at least show
you how to do that so when we get to the next lesson, it is not an issue of how do you do it,
but rather the importance of it.
[Start: 00:14:25 End 00:15:59]
So, let’s go ahead and switch back to the example from the previous lesson. As you can see, I
have MySample database opened, and we have our lone table, customers, open in our main
area so that we can change some information about our table. We are going to focus
specifically on the customer ID column, and what we want to do is set the identity property.
So, if we scroll down you can see near the bottom that there is an identity specification with a
little plus/minus area that allows us to open up some more information about whether or not
this column is defined as an identity column. So, the first thing we want to do is change the
node. Yes, we want this to be an identity column. And notice that as we get two additional
properties that we can define them by setting this to yes. We can set the identity increment
and the identity seed. The seed is the first number that we start with. So far in this example, I
know that we have already got a record No. 4 in our database. So, we will start with an
identity seed of 5. Or better yet, let’s go ahead and start with an identity seed of 8, so this
becomes very obvious as to how it is used. Next, we will set the identity increment to 1.
Now, we can set this to 2 so that when we add the next record into our database, it will be 10,
and the next record will be 12, and the next record will be 14 and so on. Or we can set it to a
negative one, which would allow us to start at, say, a million, and then count down from
there, reducing the number by one each time. Of course, that would potentially put an
artificial ceiling, but we are able to do that by defining negative one in this place. One is fine
for most purposes, so, we will leave it at 1. Now, that I have defined both of those values, I
am going to go ahead and click off of that and then select ‘save’ on the toolbar, and then I am
going to close this, and then right click and select show table data so that in the main area we
have that table view, and I am going to add a new person here Brian, Faley, and we will do
something like 4/1/2006, and I will spend 2500, and notice that I did not fill in the customer
ID. I left it null, and I hit ‘tab’ to insert this record. We, hopefully, will not get an error like
we did in the previous lesson when we had a value that we needed. But, in this case, when I
hit ‘tab’, it will automatically increment the next number to 9. So let’s do another one and
check. Notice that it increments that customer ID to 10. So, each time we add another record
into the database, it will increment that customer ID by 1.
[Start: 00:15:59 End 00:19:29]
Let’s just play devil’s advocate and delete number 10 from our database. So, I am going to
select and then hit the ‘delete’ key on my keyboard. And let’s create another one here. And
there we will use ‘2/2/2006’, and here we will spend 1400 hours and when we do that, it does
not reuse the number 10, rather it increments to number 11. Now, the reason why it does not
reuse 10, may not be so obvious to you now, but when we start talking about referential
integrity between tables and we start talking about how to relate two tables together and how
we can potentially orphan rows in one table by deleting a record from another table, you can
then understand why we did not reuse identity values once removed from the database.
Hopefully then, it will become a little bit clearer.
[Start: 00:19:29 End 00:20:51]
So, we are slowly laying groundwork, and we are just about ready now to talk about relational
databases. Specifically, how do we relate two tables of information together? What is the
benefit of it? How do you go about doing it, and how do you implement that within the visual
tools that we have available to us. And so, that is where the punch line is to all the discussion
that we had up to this point. Make sure to watch lesson number 4. And if you are enjoying
this style of training, please visit http:/www.LearnVisualStudio.NET where we have our 500
screen cam video tutorials just like this one on all topics pertaining to .NET, C#, Visual Basic,
ASP.NET and many other topics. Thank you.
[Start: 00:20:51 End 00:21:40]