Now to implement the table design,
or the database design I showed you,
I'm back here in MySQL Workbench.
And, here, I have this restaurant's table,
we worked on before, and, for the moment,
we'll just ignore that.
But I wanna add a new table now,
and there are different ways of doing that.
One of the easiest ways, here in MySQL Workbench,
is to just right-click on Tables and choose Create Table.
Alternatively, you can write the SQL command
from the ground up yourself by entering a new SQL query,
but I'll go for the easier, more graphical approach here.
Now we need a name for that table,
and since I'll store a bunch of addresses in there
I'll choose addresses as a table name.
I'll keep the Default Charset and Collation,
and the Default Engine, and, now, we can add
the different columns that we wanna have in there.
For this, I'll increase this a little bit in size.
And the first column, which I'll add,
indeed will be my IDs for the addresses.
So I wanna have an ID column so that every address
will have a unique ID, and, hence, I'll name this column id.
The Datatype can be INT, it should be my primary key
and not now, and I'll also select auto incrementing,
so that this is an integer, which automatically increments
with every new item that we add into this table
so that we never have to set the ID ourselves.
Now we also want to add a street, a street number, a city,
a postal code, and a country.
And, for this here, I'll continue with the street,
and, hence, I'll name the column, street.
And now the question is which datatype
do we wanna choose here?
And I would say a VARCHAR.
So a string is quite fitting
because a street definitely is a string.
I'll just allocate a bit more characters, here,
255 should do the trick because that will ensure
that we can also enter longer streets.
Now I will also check not now
because my street should always be set,
this value should never be omitted,
I always wanna have a street.
But other than that, I'll not set anything
and, now, we do have that street.
Now we have the id and the street.
Now I also, of course, wanna add my street number,
and I'll name this street_number,
and that's a common way of naming this.
You typically don't choose street number like this,
this CamelCase notation, which you know from JavaScript,
but, instead, typically you separate multiple words
with an underscore so that you have street number,
all lower case written like that.
Now, the question is which kind of data is a street number?
And, given its name, you might say it's a number
so we could choose an integer.
That could work, but in some countries,
or probably in most countries,
you can also have numbers like 23 A and B.
So you don't just have numbers,
but you can have annotations to those street numbers.
And, therefore, I actually, again,
wanna store some text here, hence, I'll go for varchar
and then maybe just something like 45 will do
because I don't need a super long
street number stored in there.
Now it already added the next column for me, here,
of course I'll override it, though,
because the next column I wanna store is the city.
And that, again, should be some texts,
so I'll go for VARCHAR, here, and then just store some text.
And, again, here, I wanna add a little bit more flexibility
and allow the storage of longer pieces of texts,
so I'll go for 255.
This also should be not now, and, because I forgot it,
I also wanna have not now, here, for my street number.
So, basically, all these columns should be not now.
Now, as a next step, we wanna store the postal code.
And, again, I'll name it postal_code.
Now, which data type is this?
Now, here, I have to say that I don't know if this concept
even exists in all countries in the world
and if it works the same way in all countries.
Here, in Germany, we could store an integer
because, here in Germany, where I live,
a postal code always is a number,
which is four or five digits long.
So, here, an integer would work, and, therefore,
I'll go for an integer, here, also to mix things up.
But I will say that we could also go for a varchar,
again, to store a string to have more flexibility
in case a postal code could contain non-numeric characters,
or we could also argue that we wanna store a varchar
instead of an integer because we might not do any
mathematical work with the postal code.
So we don't really need it as a number,
instead having it as a string makes perfect sense
because we read it more like text than a number,
we don't do any number operations with a postal code.
Nonetheless, to mix things up here, I'll go for an integer,
but a varchar would also be fine,
and I'll set it to not now.
And, therefore, now as a last field
I'll add the country, and the country, again,
will be a VARCHAR for me because it will be some text,
and I'll go for 255 here.
As a little side note,
we could also store countries in a separate table
so that we have a predefined list of countries
and we then only link to these countries, here,
from inside the addresses table.
I'll leave that as an extra exercise and task to you
at the end of this course section,
once you learned how you can link to other tables.
For the moment I'll just define country as some text,
which should also not be empty.
And that, therefore, that's now my final structure
for this table.
A bunch of strings, possibly strings only,
except for the id, if we would turn postal code
into a string, in my case it's an integer,
but no other value types
because it turns out that for my address data
I basically only have texts.
Now, with that, we can click Apply, here,
and this now shows us the SQL statement
that we could have also written ourselves.
And if I now run Apply, this table gets added.
Here you see it.
And now if you click on this icon, here,
you can automatically run a query on it.
Alternatively, you write this select query on your own,
and then you see the structure here
and any data that's stored in it,
but, at the moment, we have no entries, and, therefore,
we have no data in there.
But that's now the addresses table added,
that's how I added it here.
And, with that, I would say let's now work
on the rest of this slide I showed you,
and let's also adjust the restaurant's table
to fit our new requirements,
and let's also add our types and reviews tables.