00:00 - 00:05
hey there everyone my name is AES and
00:02 - 00:07
welcome to the backend Series so we are
00:05 - 00:09
pretty happy with the backend series and
00:07 - 00:11
the progress that we have made so far
00:09 - 00:13
it's been a quite fun Journey now we
00:11 - 00:15
want to structure this journey into much
00:13 - 00:17
more uh production oriented so that you
00:15 - 00:19
can also build a product and can push it
00:17 - 00:22
to the production now one of the key
00:19 - 00:23
ingredient of building such product
00:22 - 00:26
which are going to see a day in a life
00:23 - 00:28
in the production uh the most important
00:26 - 00:31
part is uh how we are going to structure
00:28 - 00:33
the data as a back engineer it's very
00:31 - 00:35
important for you to understand the
00:33 - 00:37
problem statement pick out what data we
00:35 - 00:39
want to store in the database now at
00:37 - 00:41
initial phase it doesn't really matter
00:39 - 00:44
that the database of choice is going to
00:41 - 00:45
be SQL or no SQL or which one is better
00:44 - 00:47
it doesn't really matter at the initial
00:45 - 00:49
phase when you're especially building uh
00:47 - 00:51
just an MVP the most viable product so
00:49 - 00:53
that we can see how it's behaving and
00:51 - 00:55
how our application is behaving the
00:53 - 00:56
scaling of the application is a
00:55 - 00:58
different challenge altogether and we
00:56 - 00:59
are not here to talk about that
00:58 - 01:02
challenge most of the databases whether
00:59 - 01:04
SQL or no SQL can have easily uh a
01:02 - 01:06
millions of users and once you have the
01:04 - 01:08
million user you can re architecture
01:06 - 01:10
your application pretty easily now one
01:08 - 01:12
of the goal is to understand the
01:10 - 01:14
application pick out the details and the
01:12 - 01:16
specific uh things from the problem
01:14 - 01:18
statement and figure out what
01:16 - 01:21
information about those products I would
01:18 - 01:22
like to store in my database for example
01:21 - 01:24
let's just say you want to build an
01:22 - 01:27
e-commerce application a specific
01:24 - 01:28
e-commerce application for whatever you
01:27 - 01:31
are trying to sell not all the
01:28 - 01:33
e-commerce like the the Amazon or maybe
01:31 - 01:36
flip cart or anything Which is popular
01:33 - 01:38
in your country but our goal is to
01:36 - 01:40
design a specific e-commerce in which
01:38 - 01:42
maybe you want to sell the phones or
01:40 - 01:45
maybe these remotes or my water bottle
01:42 - 01:47
whatever that is now for such kind of
01:45 - 01:48
e-commerce application of course the
01:47 - 01:50
categories are important maybe you are
01:48 - 01:52
selling different kind of bottles uh the
01:50 - 01:54
product itself is important but what
01:52 - 01:56
information about the product you want
01:54 - 01:58
to store uh maybe the weight of the
01:56 - 01:59
bottle the color of the bottle height of
01:58 - 02:01
the bottle is pretty important the
01:59 - 02:04
selling price of the bottle is important
02:01 - 02:05
the text price is important and once the
02:04 - 02:07
user has placed the order we want to
02:05 - 02:10
save information about the user but what
02:07 - 02:12
information name email ID their address
02:10 - 02:14
maybe their phone number maybe their PIN
02:12 - 02:15
code and once they have made the
02:14 - 02:18
transaction you want to store some
02:15 - 02:20
transaction information as well so the
02:18 - 02:22
first task is not to fire up your vs
02:20 - 02:25
code or your favorite code editor the
02:22 - 02:27
first task is simply to figure out what
02:25 - 02:30
information we'll be collecting and that
02:27 - 02:31
is known as from uh just thinking about
02:30 - 02:34
the problem statement or reading the
02:31 - 02:37
problem statement to moving into the
02:34 - 02:39
database or the database designing now a
02:37 - 02:41
lot of people in when they are learning
02:39 - 02:43
the back end they miss this step or kind
02:41 - 02:45
of Overlook that we're not going to do
02:43 - 02:47
that we'll be practicing enough so that
02:45 - 02:50
we understand that how the database are
02:47 - 02:52
being designed and what key information
02:50 - 02:53
is there and again yes there are formal
02:52 - 02:55
studies and books about it about the
02:53 - 02:57
database the normalization form and
02:55 - 02:59
whatnot I'm not going to go into that
02:57 - 03:01
this is not a university course this is
02:59 - 03:03
a YouTube video another YouTube video
03:01 - 03:05
but I'll give you enough of information
03:03 - 03:07
so that you feel comfortable about uh
03:05 - 03:10
the first step of building a complex
03:07 - 03:13
application in this video The Long video
03:10 - 03:14
we'll be practicing about three of such
03:13 - 03:16
applications where we are going to
03:14 - 03:18
design the backend for them or not the
03:16 - 03:19
back end but the database part of it and
03:18 - 03:21
then in the next video we'll walk
03:19 - 03:23
through that what we are about to build
03:21 - 03:26
and how we are architecturing uh that
03:23 - 03:28
application this data uh point is really
03:26 - 03:31
important and this will craft that what
03:28 - 03:34
uh what information or what activities
03:31 - 03:35
you can perform with these data points
03:34 - 03:37
so it's pretty interesting it's pretty
03:35 - 03:39
fun uh let me walk you through how we do
03:37 - 03:40
that and how I used to do that in the
03:39 - 03:44
earlier phase so let me share the screen
03:40 - 03:47
with you so this is uh this is a simple
03:44 - 03:49
tool known as eraser and uh we'll be
03:47 - 03:51
using throughout uh this entire
03:49 - 03:53
application eraser but again it's not
03:51 - 03:55
really important that we use eraser or
03:53 - 03:57
any other Tool uh there used to be other
03:55 - 03:59
tools which I used to use quite a lot so
03:57 - 04:01
let me just go ahead and walk you
03:59 - 04:05
through uh there used to be a moon
04:01 - 04:08
model Moon model I have used this quite
04:05 - 04:10
a lot it's a paid tool but pretty good
04:08 - 04:12
pretty Rock Solid I've used that in uh
04:10 - 04:14
some of the companies where I worked and
04:12 - 04:17
this helps you to design the database
04:14 - 04:18
even grab uh some scripts from it and
04:17 - 04:20
I'll walk you through how you can grab
04:18 - 04:23
the scripts out of uh not the exact
04:20 - 04:24
script but at least a basic idea of how
04:23 - 04:26
things are being done but in the
04:24 - 04:28
production special Pro uh environment
04:26 - 04:30
and the big companies we simply go ahead
04:28 - 04:32
and use things like this once we have
04:30 - 04:35
the entities their relationships and
04:32 - 04:37
everything figured out we can actually
04:35 - 04:40
just export this whole modeling into the
04:37 - 04:42
SQL or no SQL database whatever you like
04:40 - 04:45
uh one such alternative the free
04:42 - 04:47
alternative if is eraser which will help
04:45 - 04:48
us to design such database and we'll be
04:47 - 04:50
designing one here uh we'll start with
04:48 - 04:52
the basic to-do application the goal is
04:50 - 04:54
to and again we'll be doing three of
04:52 - 04:56
them so don't you worry we have enough
04:54 - 04:58
of material to practice around the first
04:56 - 05:00
one is to Simply design a symol too
04:58 - 05:02
application there will be task there
05:00 - 05:03
will be subtask and some user which will
05:02 - 05:05
be performing the task so we'll be going
05:03 - 05:08
through with that application that what
05:05 - 05:10
information I want to get uh how I want
05:08 - 05:12
to have a relationship between these
05:10 - 05:14
entities and all these things so in the
05:12 - 05:15
Eraser when you'll open the Eraser I'll
05:14 - 05:17
give you the Eraser Link in the next
05:15 - 05:19
video about what we are about to build
05:17 - 05:21
so in this eraser you can just go ahead
05:19 - 05:23
and click on this and just search for
05:21 - 05:26
the ER diagrams these are known as ER
05:23 - 05:27
diagrams entity relationships entities
05:26 - 05:30
are like products categories and
05:27 - 05:32
relationship is how they related to each
05:30 - 05:34
other I'll just select one of them and
05:32 - 05:36
this is how it gives you the sample
05:34 - 05:38
diagram and the first and important
05:36 - 05:40
thing is uh you can press this question
05:38 - 05:42
mark at the very bottom which says
05:40 - 05:44
syntax Helm and this helps you to
05:42 - 05:46
understand how these relationships are
05:44 - 05:49
written here there's a special language
05:46 - 05:51
which eraser use this language is not
05:49 - 05:54
going to be used in mango or any other
05:51 - 05:56
field but it will give us enough of idea
05:54 - 05:58
of how these things are being designed
05:56 - 06:00
there's nothing too much as you can see
05:58 - 06:02
we have this users
06:00 - 06:04
these are defined like this if you want
06:02 - 06:06
to be little bit fancy then you can just
06:04 - 06:07
uh mention couple of more things into
06:06 - 06:09
the users I'll walk you through with
06:07 - 06:11
that and if you have a one to many
06:09 - 06:13
relationship you can use this uh symbol
06:11 - 06:15
here wherever the small one points
06:13 - 06:17
that's one wherever the big one the two
06:15 - 06:20
end points are there that's many this is
06:17 - 06:21
how the language of this eraser works so
06:20 - 06:23
notice here this is one here is so it's
06:21 - 06:25
a many to one relationship this is one
06:23 - 06:27
to many relationship this is one to one
06:25 - 06:29
dash and this is many to many
06:27 - 06:30
relationships so pretty simple pretty
06:29 - 06:32
standard you can have some more
06:30 - 06:34
properties in the users you can call it
06:32 - 06:37
whatever you like users so we can have
06:34 - 06:39
an icon of user we can have a color if
06:37 - 06:41
you wish to have color purple we can
06:39 - 06:42
have diagram properties as well although
06:41 - 06:45
I'll not go much into that but this is
06:42 - 06:48
the help of how we can architecture the
06:45 - 06:49
application all right so as we can see
06:48 - 06:51
uh on the right hand side by the way if
06:49 - 06:53
you just click up here it doesn't appear
06:51 - 06:55
you have to double click on this so that
06:53 - 06:56
it appears on the right side so this is
06:55 - 06:59
code although they have ai as well that
06:56 - 07:01
can help you uh but I'll be using just
06:59 - 07:03
the code part not the AI at least in
07:01 - 07:05
this one so what we're going to do is uh
07:03 - 07:07
the first thing is let's build a simple
07:05 - 07:08
to-do application let's go ahead and
07:07 - 07:11
remove everything from here that's the
07:08 - 07:13
step one now let's see what entities we
07:11 - 07:15
are interested in into this one so the
07:13 - 07:17
first entity that I'm interested in is
07:15 - 07:19
obviously to-do so that's going to be my
07:17 - 07:21
entity number one and let's go ahead and
07:19 - 07:23
give it some icon as well so I'll just
07:21 - 07:25
go ahead and say icon probably I'll use
07:23 - 07:28
a list again you don't have to worry
07:25 - 07:30
about this this is just for fun uh no
07:28 - 07:32
such icons or list will be transferred
07:30 - 07:35
into your actual backend so I'll just go
07:32 - 07:37
ahead and this is my first entity now
07:35 - 07:40
what else do you want to have uh I guess
07:37 - 07:42
sadly we cannot zoom it much I'll try my
07:40 - 07:46
best so that it's visible yeah it's
07:42 - 07:48
decently visible so we have the to-dos
07:46 - 07:51
and once I have the to-dos what else do
07:48 - 07:52
you want to have in your application uh
07:51 - 07:55
maybe you want to have users as well so
07:52 - 07:59
let's go ahead and grab users this is my
07:55 - 08:01
users uh it will have a simple icon icon
07:59 - 08:04
that will be a
08:01 - 08:06
user this is my second entity that I'll
08:04 - 08:09
be working on and the third one is going
08:06 - 08:12
to be sub toos and sub toos will also
08:09 - 08:16
have an icon and let's call this one as
08:12 - 08:18
list again totally up to you so this is
08:16 - 08:20
my basic premises of these are the three
08:18 - 08:22
things which I am worried about now once
08:20 - 08:25
I'm done with this I want that the each
08:22 - 08:27
toos will have sub toos that's the
08:25 - 08:29
premises but let's first worry about
08:27 - 08:31
what each of these entity will consist
08:29 - 08:33
St and there's no such requirement that
08:31 - 08:35
you write it as ID you write it as
08:33 - 08:37
underscore ID there is no such thing
08:35 - 08:39
it's totally just a variable name you
08:37 - 08:40
want to go with that since we'll be
08:39 - 08:42
using mongodb it makes sense to call it
08:40 - 08:44
as ID if you're using relational
08:42 - 08:46
database feel free to call it as pkf for
08:44 - 08:49
primary key or whatever you like I'll
08:46 - 08:51
say this one is going to be a simple
08:49 - 08:54
string string my keyboard is a little
08:51 - 08:56
misplaced a string and we're going to
08:54 - 08:59
call this one as PK that's for primary
08:56 - 09:00
key to just give a reference to ourself
08:59 - 09:02
and what what else do you want to have
09:00 - 09:04
we'll be let's just say we'll be having
09:02 - 09:06
a Content onto this one that will be of
09:04 - 09:08
a type string that's personal reference
09:06 - 09:10
again and let's just say we'll be having
09:08 - 09:14
a complete uh variable there which will
09:10 - 09:16
be a further Boolean there we go looking
09:14 - 09:19
nice and easy uh then obviously we'll be
09:16 - 09:21
having a sub to-dos each to-dos will
09:19 - 09:24
have sub toos and that will be my object
09:21 - 09:26
ID this is how uh I'll be doing a
09:24 - 09:28
relationship between the to-dos and the
09:26 - 09:30
sub too so I'll be calling it as object
09:28 - 09:32
ID and there will be many of the sub
09:30 - 09:35
toos inside the to-dos so I'll refer
09:32 - 09:37
that as arrays just like this and I will
09:35 - 09:39
also refer that what kind of array will
09:37 - 09:42
be object ID means I'm referring to some
09:39 - 09:44
another entity in terms of mongodb so
09:42 - 09:47
I'll be saying that this is referencing
09:44 - 09:49
sub toos so notice here this is nice
09:47 - 09:51
diagram that is coming up this will be
09:49 - 09:54
object ID object ID is of what of these
09:51 - 09:56
sub toos so this is nice and easy now
09:54 - 09:58
each too will be mapped by users some
09:56 - 10:01
user might be creating that so I'll be
09:58 - 10:03
calling this as created by let's just go
10:01 - 10:06
ahead and call this one as created by
10:03 - 10:07
who will be creating it again some users
10:06 - 10:09
so I'll be calling it as object ID not
10:07 - 10:11
an array because not many users will be
10:09 - 10:14
creating one to-do but it's just an
10:11 - 10:16
object ID but whose relation you want to
10:14 - 10:18
mention here I'll be calling it as users
10:16 - 10:20
so this will be created by now again uh
10:18 - 10:23
two of the things that you'll be uh
10:20 - 10:26
commonly using is created at common
10:23 - 10:28
thing in the mongodb which is a date
10:26 - 10:29
field sometimes it's datetime field but
10:28 - 10:31
majority of the time it's just a date
10:29 - 10:33
field then we are going to go have
10:31 - 10:36
update at again if somebody is updating
10:33 - 10:37
I want to have a mention of this so now
10:36 - 10:39
my to-dos is looking pretty good these
10:37 - 10:42
are all information I want to collect
10:39 - 10:44
about my to-do now let's worry about
10:42 - 10:46
users how do you see your users what
10:44 - 10:48
information do you want to collect one
10:46 - 10:50
common information ID we want to refer
10:48 - 10:52
each user with the unique ID so I'll be
10:50 - 10:54
just going ahead and say hey this will
10:52 - 10:55
be a string and that string will be
10:54 - 10:58
primary key so that I can uniquely
10:55 - 11:00
identify then it's totally up to you how
10:58 - 11:03
you want to go further username will be
11:00 - 11:04
a string maybe I'll be collecting email
11:03 - 11:07
uh that will be a
11:04 - 11:09
string password of course that will be
11:07 - 11:10
encrypted but anyways that will be a
11:09 - 11:12
string as well if you have more
11:10 - 11:14
information you want to collect that's a
11:12 - 11:15
good exercise go ahead and see what data
11:14 - 11:17
more you want to collect with that
11:15 - 11:19
fixing up all these information right up
11:17 - 11:21
here is always a good idea instead of
11:19 - 11:23
just jumping into the code and figuring
11:21 - 11:25
it out on the goal I don't know what's
11:23 - 11:27
happening in my application it's always
11:25 - 11:29
a good idea let's finish this off by
11:27 - 11:33
handling the sub toos now how how do you
11:29 - 11:36
want we know that sub to-dos are a part
11:33 - 11:38
of uh to-dos so each major to-dos will
11:36 - 11:41
have subtask that we want to go but each
11:38 - 11:42
of that definitely will require uh
11:41 - 11:45
unique IDs so let's go ahead and call
11:42 - 11:47
this one as primary key this will also
11:45 - 11:49
have content which will be string uh
11:47 - 11:51
what else we have complete you need to
11:49 - 11:53
do uh complete the subtask as well that
11:51 - 11:54
will be a Boolean format so we'll be
11:53 - 11:58
going with the
11:54 - 12:00
Boolean uh what else created by created
11:58 - 12:03
by and obviously user will be creating
12:00 - 12:05
it so same stuff we'll be having object
12:03 - 12:08
ID uh but not many will be creating it
12:05 - 12:10
so we'll be calling it as user and then
12:08 - 12:13
simple created at which will be a date
12:10 - 12:15
field and uh modified at which will be
12:13 - 12:19
known as updated at and that will be
12:15 - 12:21
date so this is first fixing up that how
12:19 - 12:23
the data will look like right now we
12:21 - 12:25
haven't actually mapped any relationship
12:23 - 12:26
in that and that's okay sometimes even
12:25 - 12:29
this much gives you a lot of idea
12:26 - 12:31
because although we haven't mapped it in
12:29 - 12:33
the diagram which is important but this
12:31 - 12:35
alone tells us that how this mapping is
12:33 - 12:38
going on so this is pretty good all
12:35 - 12:40
right uh now let's go ahead and map that
12:38 - 12:42
how we want each relation to work with
12:40 - 12:44
so we'll be saying that I will be having
12:42 - 12:47
a to-dos and inside the to-dos we want
12:44 - 12:49
to have a sub to-dos that will happen so
12:47 - 12:52
that sub to-do will have uh so this is
12:49 - 12:54
Major to-do that's will have a one to
12:52 - 12:56
many relationship notice this is the one
12:54 - 12:59
the popup is coming up so one to many
12:56 - 13:01
relationship with whom with sub todos I
12:59 - 13:04
so there we go this actually draws a
13:01 - 13:07
line that What entity is related to
13:04 - 13:09
which entity and this gives us a simple
13:07 - 13:12
uh many to many or one to many
13:09 - 13:14
relationship this is one to many so
13:12 - 13:16
there can be so what we are saying
13:14 - 13:18
basically is there will be one to-do the
13:16 - 13:20
major to-do will be one and inside that
13:18 - 13:22
there could be many sub to-dos that's
13:20 - 13:24
that's the language that we are using so
13:22 - 13:26
one to many means I will be one but
13:24 - 13:29
inside me there could be many of the
13:26 - 13:31
subtask pretty simple now let's see what
13:29 - 13:34
else we can do uh todos who will be
13:31 - 13:36
creating them so created Created at not
13:34 - 13:39
created at created
13:36 - 13:41
by created by this will be a simple
13:39 - 13:43
onetoone relationship so we'll be going
13:41 - 13:45
ahead and say that hey we'll be mapping
13:43 - 13:47
it up User it's a good idea to map it
13:45 - 13:49
with the ID here we are simply saying
13:47 - 13:51
that the each to-do will be created by
13:49 - 13:52
only one user one user will be creating
13:51 - 13:55
one to-do so we'll be creating one
13:52 - 13:57
document for it pretty simple exercise
13:55 - 13:59
similarly the sub to-do also goes with
13:57 - 14:01
the same that it will also have the uh
13:59 - 14:04
created by who will be creating it
14:01 - 14:07
single user so we'll be having a simple
14:07 - 14:10
users Dot and we'll be going and linking
14:10 - 14:17
up and created by why are you giving me
14:14 - 14:19
error because I have to do this okay so
14:17 - 14:22
now you can see that we have drawn a
14:19 - 14:24
simple diagram I can zoom this out yep a
14:22 - 14:26
little now we can see we have a
14:24 - 14:27
beautiful diagram which helps us to
14:26 - 14:30
understand that how each of these
14:27 - 14:32
entities each of these diagrams are
14:30 - 14:34
working with how they are Rel related to
14:32 - 14:36
with each other and this is exercise
14:34 - 14:38
that you should do quite often quite
14:36 - 14:41
often uh it's really a nice thing to
14:38 - 14:43
work around with and this will help you
14:41 - 14:45
to solidify each of the things that
14:43 - 14:47
you're going through all right so this
14:45 - 14:49
is the first exercise that we have now
14:47 - 14:52
let's go ahead and have another exercise
14:49 - 14:54
for e-commerce I told you this video and
14:52 - 14:55
these videos obviously from now onwards
14:54 - 14:58
are going to be a little bit longer but
14:55 - 15:01
they will they will give you enough of
14:58 - 15:02
the material to consume and enjoy this
15:01 - 15:04
all right so I'll just keep this one
15:02 - 15:06
here uh for you to enjoy I'll give you
15:04 - 15:08
the even the link of this uh let's go
15:06 - 15:11
ahead and create another one have fun
15:08 - 15:13
with this one and again ER diagrams they
15:11 - 15:15
look like this so they they always look
15:13 - 15:17
like this you have to double click on
15:15 - 15:19
this to get the code part up here by the
15:17 - 15:21
way this is how it looks you can have
15:19 - 15:23
multiple of them in the same canvas I'll
15:21 - 15:25
just have it up here looks good all
15:23 - 15:28
right so the step one let's remove
15:25 - 15:30
everything and this is how it works now
15:28 - 15:32
let's just say we we are designing this
15:30 - 15:34
entity diagram for an e-commerce store
15:32 - 15:39
let's Zoom this a little bit I think
15:34 - 15:41
this is good enough yeah all right so
15:39 - 15:42
what are all the things you are worried
15:41 - 15:44
about when you're designing an
15:42 - 15:47
e-commerce store the first thing I'm
15:44 - 15:49
always worried about are users I'm very
15:47 - 15:52
worried about users so I'll be saying
15:49 - 15:53
that icon and user this icon is just
15:52 - 15:55
nothing it's just a fancy way of
15:53 - 15:57
denoting that it looks good in the
15:55 - 16:00
visual all right so we have user what
15:57 - 16:02
else is bothering you maybe
16:00 - 16:04
products you will have many of them so
16:02 - 16:07
I'll just go ahead and say icon and that
16:04 - 16:08
icon will be there are so many of them
16:07 - 16:10
you can choose a lot of them some of
16:08 - 16:13
them I remember uh but again nothing to
16:10 - 16:15
worry so we have users uh we have
16:13 - 16:17
products what else are you worried about
16:15 - 16:21
in an e-commerce maybe categories so
16:17 - 16:23
let's go ahead and say Cate Gories
16:21 - 16:27
category categories however you want to
16:23 - 16:30
go with that icon and we'll be
16:27 - 16:31
having package pack I think we have a
16:31 - 16:39
icon U do we have oops not icons icon
16:37 - 16:41
yeah we have a package icon looks nice
16:39 - 16:44
all right what else are you worried
16:41 - 16:46
about we have users we have uh products
16:44 - 16:48
we have categories we have order items
16:46 - 16:50
as well whenever somebody is making an
16:48 - 16:53
order we will be having order as well as
16:50 - 16:55
order items inside that each order will
16:53 - 16:59
consist of multiple of these items so uh
16:55 - 17:01
let's first worry about order items and
16:59 - 17:03
that will also have an icon and what
17:01 - 17:05
icon list is good enough I don't
17:03 - 17:08
remember much of them so that's why
17:05 - 17:13
you'll be finding me reusing them all
17:08 - 17:17
right so order items icon is list my bad
17:13 - 17:17
wrong choice of parenthesis should be
17:17 - 17:22
brackets all right looking good and of
17:20 - 17:24
course since we have this much now we
17:22 - 17:27
will be having order
17:24 - 17:30
orders and we'll be having an icon that
17:27 - 17:33
icon will be list again and do we have
17:30 - 17:36
others as well like something related to
17:36 - 17:40
post we have postmen but we don't have
17:39 - 17:43
I'll go with the list
17:40 - 17:46
again yeah I don't remember much anyways
17:43 - 17:48
you got the idea having fun between uh
17:46 - 17:50
doing all of this is equally important
17:48 - 17:52
that how we go with that okay uh I guess
17:50 - 17:55
these are enough uh if you find anything
17:52 - 17:57
more just go ahead add it more have your
17:55 - 17:59
own fun with this that how you want to
17:57 - 18:02
go first thing is always worry about for
17:59 - 18:04
the each individual entity that how you
18:02 - 18:05
want to deal with that again I don't
18:04 - 18:07
have much I'll just go ahead and call
18:05 - 18:12
this one we'll have an ID which will be
18:07 - 18:14
a string primary key PK not like that PK
18:12 - 18:17
so this will be having a primary key
18:14 - 18:19
will have a username for this one again
18:23 - 18:28
password string maybe you want to have
18:26 - 18:30
PIN code and whatnot just feel free to
18:28 - 18:32
add this is your exercise this is your
18:30 - 18:35
way of doing the fun so once you have
18:32 - 18:39
this uh products products are usually uh
18:35 - 18:41
little bit like more complex compared to
18:39 - 18:43
the users uh so let's go ahead and try
18:41 - 18:45
to make it a little bit more complex
18:43 - 18:47
again it's not complex it just have it
18:45 - 18:49
is having many fields as compared to
18:47 - 18:51
others so we'll be having each product
18:49 - 18:53
needs to have a unique ID so that we can
18:51 - 18:55
identify that uniquely in the database
18:53 - 18:57
name will be probably have a description
18:55 - 19:00
good idea to provide description to the
18:57 - 19:03
user uh product image yes image uh
19:00 - 19:05
product image uh this will be a string
19:03 - 19:07
because the usual way of storing the
19:05 - 19:11
image is hand it over to third party
19:07 - 19:13
like AWS or Cloud Nary any other
19:11 - 19:16
Solutions uh we'll be just storing the
19:13 - 19:19
URL of it so that is why this is image
19:16 - 19:22
uh price very important uh this will be
19:19 - 19:24
a number uh what else a stock do we have
19:22 - 19:27
this item in the stock so we'll be
19:24 - 19:29
having a number about that uh category
19:27 - 19:31
category Cate
19:29 - 19:33
gory this field will be mapped to
19:31 - 19:35
another field so we'll be referring that
19:33 - 19:37
as an object ID but whose object ID to
19:35 - 19:40
the categories so this mentioned that
19:37 - 19:42
hey this is an object ID map to another
19:40 - 19:44
one uh pretty nice uh somebody will be
19:42 - 19:47
creating that so owner of this product
19:44 - 19:50
so we'll be going with object ID who
19:47 - 19:52
will be owner users at least somebody
19:50 - 19:55
from the users will be owner of this one
19:52 - 19:57
and what else uh created at updated at
19:55 - 20:00
we can add those fields into users as
19:57 - 20:02
well that's is why I'm saying having
20:00 - 20:04
discussion here at this point is always
20:02 - 20:06
a good idea instead of writing the code
20:04 - 20:09
updated at which will be a date field
20:06 - 20:10
all right so product looks pretty pretty
20:09 - 20:13
complex but it's good it's good
20:10 - 20:15
discussion categories categories are
20:13 - 20:17
usually simple there is nothing much but
20:15 - 20:20
it's up to you how complex you want to
20:17 - 20:25
add this or not so I'll be having a
20:20 - 20:28
ID uh that will be string primary key of
20:25 - 20:30
course so there we go what else you want
20:28 - 20:32
I just want usually just the name in
20:30 - 20:35
this that's usually my choice but again
20:32 - 20:37
it's up to you created at and we'll be
20:35 - 20:39
having updated at both of these fields
20:37 - 20:41
uh simple date field and simple date
20:39 - 20:44
field there we go our category is all
20:41 - 20:47
done ready no problem there uh order
20:44 - 20:50
items yeah this is important because
20:47 - 20:53
whenever you're placing an order uh each
20:50 - 20:56
order has number of order items so first
20:53 - 20:57
of all order item let's say we can have
20:56 - 20:59
everything has a unique ID whether
20:57 - 21:01
that's underscore ID you U ID primary
20:59 - 21:04
key num strings whatever you want but
21:01 - 21:06
should have a unique ID so we're going
21:04 - 21:08
to say that each one of them will have
21:06 - 21:12
multiple products so we'll be calling
21:08 - 21:15
this one as products or product ID let's
21:12 - 21:18
store product ID and in that we'll be
21:15 - 21:22
having an object ID and that will be
21:18 - 21:24
coming up from products now it's up to
21:22 - 21:26
you that you want to call this as each
21:24 - 21:28
order item will have one product or you
21:26 - 21:31
want to call them as Ord will be
21:28 - 21:32
collection of multiple order item how
21:31 - 21:35
you want to arrange your data totally up
21:32 - 21:36
to you leaving that as an open-ended
21:35 - 21:39
discussion that how you want to go I
21:36 - 21:41
want to call each order item as just one
21:39 - 21:43
product so storing the ID of that
21:41 - 21:46
product only but I'll store the quantity
21:43 - 21:49
of that as well quantity which will be a
21:46 - 21:53
number so that I know that each order
21:49 - 21:55
item orders order item will have one
21:53 - 21:57
product and how many quantities to ship
21:55 - 21:59
for it that's a good design uh nothing
21:57 - 22:01
to argue on that
21:59 - 22:04
and let's see orders this is important
22:01 - 22:06
because we have orders so again first
22:04 - 22:08
thing without even thinking about it I
22:06 - 22:10
always go like this string primary key
22:08 - 22:12
oops what did I
22:10 - 22:15
did what did I
22:12 - 22:17
did oops uh let's double click on that
22:15 - 22:19
accidentally pressed wrong Keys thank
22:17 - 22:21
goodness there is a command Z otherwise
22:19 - 22:22
we would have to re-record the video uh
22:22 - 22:28
yeah okay so primary key there we go now
22:25 - 22:29
orders orders that's we were talking
22:29 - 22:32
so first of all each order will be
22:32 - 22:37
customer let's call this as customer uh
22:35 - 22:39
user whatever you want to call this one
22:37 - 22:41
will be object ID and will be linked to
22:39 - 22:44
your user all right good or users yeah
22:41 - 22:46
we called it as users all right that's
22:44 - 22:48
the first part we'll have order items
22:46 - 22:51
multiple order items so we'll be having
22:48 - 22:53
order items this will be of course
22:51 - 22:55
object ID but an array of object ID
22:53 - 22:57
because multiple things will be there
22:55 - 22:59
and this will be coming up from order
22:57 - 23:01
items there we go nice structure will
22:59 - 23:03
also link that when you are placing the
23:01 - 23:05
order we'll be having an address at that
23:03 - 23:07
time we need to take address you can
23:05 - 23:09
take address from the users account as
23:07 - 23:10
well uh then we can design the
23:09 - 23:13
functionality that before placing the
23:10 - 23:15
order uh Mark that where you want to or
23:13 - 23:17
select multiple of these address depends
23:15 - 23:19
how you want to architecture your
23:17 - 23:22
application we'll be having another one
23:19 - 23:25
which will be a string uh what else
23:22 - 23:26
status yeah that's important status uh
23:25 - 23:29
each order will have a status and that's
23:26 - 23:31
a different thing uh enum which is
23:29 - 23:33
multiple states that you can select from
23:31 - 23:37
so for example we'll be having a pending
23:33 - 23:40
State and then we can have
23:40 - 23:46
State and we'll be having
23:42 - 23:48
a delivered state so multiple enams
23:46 - 23:51
means there are multiple options only
23:48 - 23:53
select from these options only and if
23:51 - 23:56
you want to store maybe payment ID out
23:53 - 23:59
of it that while each order will should
23:56 - 24:02
have a uh payment ID from wherever you
23:59 - 24:06
have taken the payment maybe uh stripe
24:02 - 24:08
PayPal razor pay PTM whatever is popular
24:06 - 24:10
in your country so we'll be having a
24:08 - 24:12
created at which will be a date field
24:10 - 24:14
and usually there is no modified but
24:12 - 24:16
still good idea to keep
24:14 - 24:18
updated all right so this is what we
24:16 - 24:20
have designed so far again this is
24:18 - 24:23
looking much beautiful and much more
24:20 - 24:24
codable now that we have practiced it
24:23 - 24:26
but one thing is still missing that how
24:24 - 24:28
we are going to relation provide a
24:26 - 24:29
relation between each one of them
24:28 - 24:31
because they do need to have some
24:29 - 24:33
relation with each other we have
24:31 - 24:34
mentioned the relation already so first
24:33 - 24:36
of all let's go with the product
24:34 - 24:39
categories that's a very simple straight
24:36 - 24:42
forward so products uh will have a
24:39 - 24:44
category and they will have a onetoone
24:42 - 24:46
relationship with the categories so
24:44 - 24:49
we'll be having categories. ID so they
24:46 - 24:52
have a simple relationship uh a product
24:49 - 24:54
can only belong to one category and uh
24:52 - 24:57
that's it that's the relationship is
24:54 - 24:59
saying product category belongs to one
24:57 - 25:01
product Belongs to Only One category
24:59 - 25:04
product owner there could only be one so
25:01 - 25:08
simple products do owner that will have
25:04 - 25:10
a simple relationship uh as users. ID
25:08 - 25:13
very simple relationship each product
25:10 - 25:14
can be created by one uh order items
25:13 - 25:18
should also have S similar things so
25:14 - 25:19
order items and we'll have a product ID
25:18 - 25:21
this will have a simple one toone
25:19 - 25:24
relationship with the product
25:21 - 25:26
straightforward and product ID so we can
25:24 - 25:28
see pretty simple pretty straightforward
25:26 - 25:31
that whenever you are making
25:28 - 25:33
uh an order item the product ID that we
25:31 - 25:34
discussed will be linked to one product
25:34 - 25:40
simple all right then uh there's one
25:37 - 25:44
more interesting one uh
25:40 - 25:48
orders uh do customer we also want to
25:44 - 25:50
have this one so orders do
25:48 - 25:53
customer uh they will be having a one
25:50 - 25:57
Rel on toone relationship with the user
25:53 - 25:59
each order will be placed by a user only
25:57 - 26:01
and notice how nicely they actually
25:59 - 26:04
rearrange the architecture and structure
26:01 - 26:07
pretty nice all right uh one more what
26:04 - 26:10
is remaining order items yeah so order
26:07 - 26:12
items each order can have multiple of
26:10 - 26:15
the order items so depends on how you
26:12 - 26:21
want to write it so we'll be having
26:15 - 26:25
orders orders do order items we can have
26:21 - 26:29
many of them so we'll be having order
26:25 - 26:33
items dot ID so what we are basically
26:29 - 26:36
saying that uh order items can be
26:33 - 26:38
multiple in an order so if there is
26:36 - 26:40
order and this is what we have said so
26:38 - 26:42
notice here in the orders we said that
26:40 - 26:44
there are order items so notice we
26:42 - 26:47
mentioned this as object ID and array of
26:44 - 26:49
it that means each order can have a
26:47 - 26:50
multiple of order items and that's
26:49 - 26:52
exactly what we are saying here uh there
26:50 - 26:54
could be multiple languages of saying
26:52 - 26:56
which way to point the arrow depends on
26:54 - 26:58
how you want to go the whole idea is you
26:56 - 27:00
understand this relationship and
26:58 - 27:03
again we cannot actually download the
27:00 - 27:05
script into the SQL or no SQL database
27:03 - 27:07
here but in the moon modeler and the
27:05 - 27:09
professional tool that you use in your
27:07 - 27:10
corporate and Company uh this is done
27:10 - 27:14
often and this is where a lot of
27:12 - 27:18
brainstorming is done not in the code
27:14 - 27:20
part code part is relatively simple uh
27:18 - 27:21
but this is where the majority of how
27:20 - 27:22
you want what data you want to collect
27:21 - 27:25
in your application that's why the
27:22 - 27:26
applications are being designed I know
27:25 - 27:28
this is a good practice you want to do a
27:26 - 27:30
little bit more and I'll give you some
27:28 - 27:33
of the practice exercise as well so now
27:30 - 27:35
I'll give let's design one more it's not
27:33 - 27:37
going to be that complex but since I've
27:35 - 27:39
discussed that in my other channel as
27:37 - 27:42
well I'll discuss that let's create one
27:39 - 27:44
more uh ER diagram uh just go like that
27:42 - 27:46
and again go select all of this and
27:44 - 27:49
clear all this uh this time we are
27:46 - 27:51
designing a hospital management system
27:49 - 27:53
yeah uh again not very complex but a
27:51 - 27:56
basic Hospital you are just starting it
27:53 - 27:58
out how you want to uh nail it down so
27:56 - 28:00
first of all uh the hospital system and
27:58 - 28:02
Hospital management system you need to
28:00 - 28:04
understand that patient goes to multiple
28:02 - 28:07
hospital at least in India and uh
28:04 - 28:08
doctors also visit multiple hospitals as
28:07 - 28:10
well so we are designing this for
28:08 - 28:12
Hospital there could be patients and
28:10 - 28:15
patients do have records and there are
28:12 - 28:16
doctors who keep on visiting multiple
28:15 - 28:18
hospitals as well but they are
28:16 - 28:21
Standalone entity as well so uh of
28:18 - 28:23
course hospital is a standalone entity
28:21 - 28:25
doctors are a standalone entity the
28:23 - 28:27
patients are Standalone entity and the
28:25 - 28:29
patients record is also a standalone
28:27 - 28:32
entity there could be multiple factors
28:29 - 28:33
about reports and labs and whatnot but
28:32 - 28:35
let's start we need to start somewhere
28:33 - 28:37
so that we can iterate over it so first
28:35 - 28:40
of all what we're going to do is we have
28:37 - 28:42
hospitals all right we'll definitely
28:40 - 28:44
have some icons and one icon that I
28:42 - 28:46
specifically remember for this one is
28:44 - 28:48
building yes I remember this one all
28:46 - 28:50
right so we have this one Hospital
28:48 - 28:52
should I zoom it yep we need zooming we
28:50 - 28:56
need zooming who hates
28:52 - 29:00
Zoom so Hospital okay uh
28:56 - 29:03
patient p patient patient patience yeah
29:00 - 29:06
good good enough we will be having icon
29:03 - 29:09
and let's call this one as user short
29:06 - 29:11
but handy okay uh we have hospital we
29:09 - 29:12
have patient we will have definitely
29:14 - 29:19
doctors do we have icon for a doctor
29:16 - 29:21
tell me please we have icon for Doctor
29:19 - 29:23
we have a Docker but not the doctor
29:21 - 29:25
Docker can I use a Docker n doesn't look
29:23 - 29:29
good doesn't look
29:25 - 29:32
good we have oh we have stethoscope icon
29:29 - 29:34
did I say it correct or not all right
29:32 - 29:36
that's nice okay uh what else we want to
29:34 - 29:39
have we want to have medical records as
29:36 - 29:40
well to have this one so let's have this
29:40 - 29:47
well we will have medical records each
29:44 - 29:49
record will be tied only and only to one
29:47 - 29:53
user or one patient itself so we'll keep
29:49 - 29:55
that in mind so icon will be off I know
29:53 - 29:58
this there is icon of clipboard that
29:55 - 30:01
looks like a record and there we go
29:58 - 30:02
all right so currently we are just uh
30:01 - 30:04
handling this much let's see these four
30:02 - 30:07
entities how we can collect the data
30:04 - 30:09
about them uh have a small discussion
30:07 - 30:11
and fun discussion with them so what
30:09 - 30:13
we're going to do is let's just say
30:11 - 30:15
we'll have underscore ID obviously
30:13 - 30:18
always goes like that this will be our
30:15 - 30:20
primary key all right what else each
30:18 - 30:23
Hospital have a name so obviously let's
30:20 - 30:23
store that uh
30:23 - 30:28
address address and sometimes you go
30:27 - 30:32
with like this address line one which
30:28 - 30:34
will be a string and maybe address line
30:32 - 30:36
two which will be a string depends on
30:34 - 30:39
you how you want to craft your
30:36 - 30:43
application City will also be a
30:39 - 30:44
string and what else pin code it's
30:43 - 30:46
always a good idea to take PIN code and
30:44 - 30:49
string because some in some countries
30:46 - 30:51
the PIN code is not comprised of just
30:49 - 30:53
numbers they are comprised of some
30:51 - 30:55
alphabets as well it's a good idea to
30:55 - 30:59
and specialization of course every
30:58 - 31:01
hospital has some or the other
30:59 - 31:03
specialization or maybe many so let's
31:01 - 31:07
take it as string but an array of string
31:03 - 31:11
good idea and then our classic created
31:07 - 31:13
at which will be a date and updated at
31:11 - 31:15
which will be a date again there we go
31:13 - 31:17
nice and easy so we have built the
31:15 - 31:19
entire building of the hospital now how
31:17 - 31:22
we want to go with the patients so let's
31:19 - 31:25
go up here uh again always starts with a
31:22 - 31:27
unique ID so that you can identify each
31:25 - 31:29
record with that so we'll be going with
31:27 - 31:32
the string primary key of course so
31:29 - 31:34
there we go okay patient patient has a
31:32 - 31:36
name so let's go ahead and work with
31:36 - 31:44
and diagnosed with uh this probably will
31:41 - 31:46
be a consulted with diagnosed with I
31:44 - 31:49
don't know if it is a good name or not
31:46 - 31:52
uh but here my intention is to store uh
31:49 - 31:55
whose doctor he has recommended with uh
31:52 - 31:57
I'm not storing what the problem the
31:55 - 31:58
patient is facing what sickness he's
31:57 - 32:00
facing in here I'll store that in the
31:58 - 32:03
medical record that's always a good idea
32:00 - 32:06
so I'm just saying that diagnosed with
32:03 - 32:08
or consulted with again totally just and
32:06 - 32:11
again it's a good idea to store the
32:08 - 32:12
address of the user you want to go with
32:11 - 32:15
address line one line two that's totally
32:12 - 32:20
up to you and I missed a
32:15 - 32:23
d address all right uh what else age
32:20 - 32:26
definitely we should store that
32:23 - 32:28
number uh gender good idea to store that
32:26 - 32:30
it's a good one to have an for this one
32:28 - 32:34
so we'll go with the
32:30 - 32:36
m and we'll go with the F just like this
32:34 - 32:39
and we'll mention o just like that if
32:36 - 32:41
you have more it's your choice uh what
32:39 - 32:45
else we want to go uh blood group so
32:41 - 32:47
we'll have blood group uh blood group it
32:45 - 32:51
should also be enum but since I'm not a
32:47 - 32:53
doctor I have no knowledge of giving
32:51 - 32:54
them the option of selecting with them
32:53 - 32:55
so in this case I'll just go with the
32:54 - 32:57
string this is where you should consult
32:55 - 32:59
some doctor that hey I want a list of
32:57 - 33:04
blood grou or something like that uh
32:59 - 33:08
patient also might be admitted so
33:04 - 33:11
admitted in and that will be an object
33:08 - 33:13
ID uh so that we can have a refer that
33:11 - 33:16
in which hospital he was admitted all
33:13 - 33:20
right and then regular stuff created at
33:16 - 33:22
updated at created at date and we'll be
33:20 - 33:25
having updated at date so there we go
33:22 - 33:26
again you could have added up more
33:25 - 33:29
Fields then obviously more controllers
33:26 - 33:33
more logic that be written okay uh next
33:29 - 33:35
up is doctors all right what information
33:33 - 33:39
you want to store about the doctors okay
33:35 - 33:40
let's do this ID uh underscore ID my bad
33:39 - 33:41
and again it's not compulsory you have
33:40 - 33:43
to write underscore ID I'm just
33:41 - 33:45
referencing for
33:45 - 33:52
string primary key and what else each
33:49 - 33:54
doctor have a name that's obvious and
33:52 - 33:56
salary hospital do pay salary pretty
33:54 - 34:00
good one to the doctors and they should
34:00 - 34:05
qualification qualification each doctor
34:03 - 34:09
have different qualifications multiple
34:05 - 34:11
qualifications in fact and
34:09 - 34:15
experience in years maybe you want to
34:11 - 34:16
store that display that as your hospital
34:16 - 34:20
uh doctors can work into multiple
34:19 - 34:22
hospitals as well so where this doctor
34:20 - 34:28
is available maybe want to store that as
34:22 - 34:32
well uh Works in hos hospit
34:28 - 34:33
STS that will be obviously an object ID
34:32 - 34:35
but an array of object ID because
34:33 - 34:37
multiple will be stored and this will be
34:35 - 34:40
coming up from
34:37 - 34:42
hospitals all right what else do you
34:40 - 34:45
want to store for doctor no idea I'll
34:42 - 34:49
just end it up by created at date and
34:45 - 34:51
updated at and date I I'll just leave it
34:49 - 34:53
up here then comes up is the medical
34:51 - 34:55
record yeah this is where things can be
34:53 - 34:57
very interesting you can store a lot of
34:55 - 34:59
information but I'll keep it basic
34:57 - 35:00
because I don't have much experience of
34:59 - 35:02
working in hospitals or I have never
35:00 - 35:05
worked in a big scale Hospital
35:02 - 35:08
application as well uh patient ID
35:05 - 35:11
patient ID and that patient ID will come
35:08 - 35:16
up from object ID of
35:11 - 35:18
patient patients yeah patience and uh
35:18 - 35:24
at examined at and that will be date or
35:22 - 35:28
rather datetime field that when he was
35:24 - 35:29
examined and the problem uh I don't know
35:28 - 35:31
what's the better word for that so
35:29 - 35:35
please excuse me that I'll just call it
35:31 - 35:37
as problem I can say description or
35:35 - 35:40
problem issue whatever you want to call
35:37 - 35:44
uh this one will be string and create a
35:40 - 35:46
at which will be a date and update at
35:44 - 35:47
which will also be a so there we go we
35:46 - 35:50
have designed a basic Hospital
35:47 - 35:52
management system now it's time that we
35:50 - 35:55
Define all the relationships between
35:52 - 35:56
them again relationship most of them we
35:55 - 35:58
have already defined while working with
35:56 - 36:01
them but let's go with there so first of
35:58 - 36:03
all is uh patient is going to be
36:01 - 36:06
admitted in hospital so that's the easy
36:03 - 36:09
relationship to work on with so patients
36:06 - 36:11
has this admitted in field which will be
36:09 - 36:12
a onetoone relationship because at a
36:11 - 36:16
time you can be admitted only in one
36:12 - 36:18
hospital so will be hospitals ID so
36:16 - 36:20
that's the first relationship we have uh
36:18 - 36:24
doctor Works in multiple hospitals so
36:20 - 36:26
we'll be saying doctors and works in
36:24 - 36:28
Works in hospitals so they he can work
36:26 - 36:31
in many hospitals
36:28 - 36:36
so one doctor many hospitals so one to
36:31 - 36:39
many relationship hospitals do ID is
36:36 - 36:42
fine I guess so doctor Works in multiple
36:39 - 36:44
hospital one to many and there could
36:42 - 36:46
there could only be one medical record
36:44 - 36:51
for each of the patients so let's also
36:46 - 36:54
fix that so medical record and uh has a
36:51 - 36:57
patient ID which is an object ID has one
36:54 - 36:59
toone relationship with the patients uh
36:57 - 37:01
primary key is fine enough so we can see
36:59 - 37:04
we have designed this nice relationship
37:01 - 37:06
entity diagram and when when we are
37:04 - 37:08
coding actually this it is much much
37:06 - 37:10
easier to keep it separate on a paper or
37:08 - 37:12
a screen and just keep on writing the
37:10 - 37:13
code that hey this is what we are going
37:12 - 37:15
through this is what we are working
37:13 - 37:17
through so I hope this gives you enough
37:15 - 37:19
of idea that how applications are
37:17 - 37:21
designed in production and we have
37:19 - 37:23
multiple of them so we have designed
37:21 - 37:25
three of them again you go ahead and
37:23 - 37:27
design your own uh I have used this nice
37:25 - 37:28
handy tool eraser but it's not the only
37:27 - 37:30
one one there are many others I find
37:28 - 37:32
this one handy uh pretty nice and
37:30 - 37:34
beautiful tool so that's why we use this
37:32 - 37:36
all right so I hope this gives you
37:34 - 37:37
enough of idea of how these applications
37:36 - 37:39
are designed and how they are being
37:37 - 37:42
worked through now it's time for your
37:39 - 37:44
assignment and your task uh go ahead and
37:42 - 37:46
design a simple Library management
37:44 - 37:48
system and try to design a Content
37:46 - 37:51
management system somewhat like Netflix
37:48 - 37:53
or uh Amazon Prime or something uh think
37:51 - 37:56
how you can design that the categories
37:53 - 37:58
the movies the seasons and the users of
37:56 - 38:00
course who is watching it so try to
37:58 - 38:02
design a diagram around that also try to
38:00 - 38:05
design something uh related to library
38:02 - 38:07
management system uh libraries is pretty
38:05 - 38:09
straightforward we have categories we
38:07 - 38:11
have books and who is the user who is
38:09 - 38:13
borrowing the books so dates time and
38:11 - 38:14
try to design these application the more
38:13 - 38:17
you'll be designing the better you'll
38:14 - 38:19
become uh there's no shortcut for is uh
38:17 - 38:20
it goes like this only in the next video
38:19 - 38:22
I'll walk you through that what we have
38:20 - 38:24
designed for this entire long short
38:22 - 38:26
application and I'll give you the link
38:24 - 38:27
of that as well you can access that from
38:26 - 38:29
the description in the next video and
38:27 - 38:31
we'll discuss that how we have designed
38:29 - 38:32
this taking YouTube in the mind in the
38:31 - 38:34
broader picture we are mixing up YouTube
38:32 - 38:36
with the Twitter as well uh so we'll
38:34 - 38:38
walk you through with that that how the
38:36 - 38:40
complex architecture that we have
38:38 - 38:42
designed so that we can write a really
38:40 - 38:44
really complex back end not the toy one
38:42 - 38:46
the real production grade one all right
38:44 - 38:48
so quite a lot of stuff uh that's it for
38:46 - 38:50
this video uh let's go ahead and catch
38:48 - 38:53
up in the next video to understand more
38:50 - 38:57
about these entity relationship diagrams
38:53 - 38:57
catch you up in the next one
video to article