In this lesson, you’ll learn about: data modeling and resource management in Ruby on Rails, from conceptual design to real-world implementation and testing1. Conceptual Data Modeling🔹 Core concepts:
A well-designed data model is the foundation of any scalable application2. Designing Relationships🔹 Relationship types:
Relationships define how data connects and interacts across the system3. Implementing Models in RailsUsing Ruby on Rails:🔹 Command:
Rails automates database structure creation through generators4. Database Migrations🔹 Command:
Migrations allow you to evolve your database safely over time5. Active Record (ORM)🔹 Concept:
ORM removes the need to write raw SQL for most operations6. Defining Associations🔹 In models:class Company < ApplicationRecord has_many :stock_prices end class StockPrice < ApplicationRecord belongs_to :company end 👉 Key Insight
Associations enable powerful and intuitive data access in Rails7. Working with Rails Console🔹 Command:
The console is one of the most powerful tools for learning and debugging8. CRUD Operations in Practice🔹 Create:company = Company.create(name: "Apple") 🔹 Read:Company.all 🔹 Update:company.update(name: "Apple Inc.") 🔹 Delete:company.destroy 👉 Key Insight
CRUD operations are the core of any data-driven application9. Querying Relationships🔹 Examples:company.stock_prices stock_price.company 👉 Key Insight
Rails makes relational queries simple and readable10. Testing Data Integrity🔹 What to verify:
Testing ensures your data model behaves correctly before productionKey Takeaways
👉 Implement it in Rails generators and migrations
👉 Test and validate it interactivelyMental ModelDesign entities → define attributes → create models → migrate database → set relationships → test in console → validate data integrity
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
- Entities → represent real-world objects (e.g., Company, Stock)
- Attributes → properties of entities (name, price, symbol)
- Data types → string, integer, decimal, etc.
- Primary Key (ID) → unique identifier for each record
- Foreign Key → links one entity to another
A well-designed data model is the foundation of any scalable application2. Designing Relationships🔹 Relationship types:
- One-to-Many (most common in Rails apps)
- A Company has many stock prices
- A Stock Price belongs to a company
Relationships define how data connects and interacts across the system3. Implementing Models in RailsUsing Ruby on Rails:🔹 Command:
- rails generate model Company name:string
- rails generate model StockPrice price:decimal company:references
- Model files are created
- Migration files are generated
- Database schema is defined
Rails automates database structure creation through generators4. Database Migrations🔹 Command:
- rails db:migrate
- Apply structural changes to the database
Migrations allow you to evolve your database safely over time5. Active Record (ORM)🔹 Concept:
- Maps Ruby classes to database tables
- Class → Table
- Object → Row (record)
- Company model ↔ companies table
ORM removes the need to write raw SQL for most operations6. Defining Associations🔹 In models:class Company < ApplicationRecord has_many :stock_prices end class StockPrice < ApplicationRecord belongs_to :company end 👉 Key Insight
Associations enable powerful and intuitive data access in Rails7. Working with Rails Console🔹 Command:
- rails console
- Interact with models in real time
- Test logic without running the full app
The console is one of the most powerful tools for learning and debugging8. CRUD Operations in Practice🔹 Create:company = Company.create(name: "Apple") 🔹 Read:Company.all 🔹 Update:company.update(name: "Apple Inc.") 🔹 Delete:company.destroy 👉 Key Insight
CRUD operations are the core of any data-driven application9. Querying Relationships🔹 Examples:company.stock_prices stock_price.company 👉 Key Insight
Rails makes relational queries simple and readable10. Testing Data Integrity🔹 What to verify:
- Records are saved correctly
- Relationships work as expected
- Queries return correct results
Testing ensures your data model behaves correctly before productionKey Takeaways
- Data modeling starts with entities, attributes, and relationships
- Primary and foreign keys connect your data logically
- Active Record simplifies database interaction
- Associations enable powerful data queries
- Rails console is essential for testing and debugging
👉 Implement it in Rails generators and migrations
👉 Test and validate it interactivelyMental ModelDesign entities → define attributes → create models → migrate database → set relationships → test in console → validate data integrity
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
So back in twenty fourteen, there was this massive international
corporation that ended up losing like millions of dollars in
a single afternoon.
Speaker 2 (00:08):
Oh yeah, I know exactly what you're talking about, the
ultimate night mercenario, right.
Speaker 1 (00:11):
And the crazy thing is it wasn't a market crash,
It wasn't you know, a bad investment strategy or anything.
It was a complete system failure caused by a single
word spelled wrong in a database.
Speaker 2 (00:23):
Millions of rows of data, all brought down by one typo.
Speaker 1 (00:26):
Yeah exactly. Someone basically just typed a plain text name
in a field that was expecting something else, and the
entire math engine behind the company's software just it completely
folded in on itself.
Speaker 2 (00:38):
Which is terrifying, honestly, because that usually happens when people
try to take the messy, infinite complexity of the real
world and just kind of cram it into a computer
without setting up rigid rules first, right.
Speaker 1 (00:50):
Which brings us to our mission for today's deep dive.
We're going to talk about the invisible structures that prevent
that exact kind of catastrophe. So imagine for a second
that you are listener, want to build your own personal
financial tracking system.
Speaker 2 (01:04):
Okay, I like where this is going.
Speaker 1 (01:06):
Yeah, so you want to track historical stock prices. Say
you start with Tesla because you want to run some analysis,
but you know you're ambitious. You know you might want
to add Facebook or Google or literally any other company
down the line. Right, You need flexibility exactly, So how
do you translate that real world goal into a clean,
functioning digital system. Today we are driving deep into data modeling. Specifically,
(01:31):
we're going to take a conceptual idea and bring it
to life using a framework called Rubyon.
Speaker 2 (01:36):
Rails, which is such an incredibly powerful tool for this,
it really is.
Speaker 1 (01:40):
So we're going to break the world down into what
we call entities, link them all together, and seamlessly translate
them into a living database. By the end of this
deep dive, you're going to understand the hidden architecture powering
the apps you use every single day.
Speaker 2 (01:54):
And honestly, the best part about this whole process is
that the very first step of building you know, atproof system,
it actually has absolutely nothing to do with writing.
Speaker 1 (02:03):
Code, well really no code at all.
Speaker 2 (02:05):
Zero code. Before you even touch a keyboard. You have
to look at your overarching goal, in this case, tracking stocks,
and you just start isolating the mounds in your story.
You have to identify the entities.
Speaker 1 (02:16):
Okay, So an entity is just what a generic concept
that represents a real world thing.
Speaker 2 (02:21):
Exactly, It's a generalized Now.
Speaker 1 (02:23):
Okay, well, if I look at my financial tracker, my
first instinct is just to say, well, Tesla is the
main player here. So Tesla is my first entity.
Speaker 2 (02:32):
And see that instinct right there? That is exactly what
backs early developers into a massive corner. Really, how so,
because Tesla is just one specific instance of a thing.
If you create an entity and actually name it Tesla,
you've hard coded your entire system to only ever understand
that one single business.
Speaker 1 (02:51):
Oh I see right.
Speaker 2 (02:52):
So the key to data modeling is stepping back and asking,
what is Tesla a type of Ah?
Speaker 1 (02:57):
Okay, it's a company.
Speaker 2 (02:58):
Exactly, it's a company. Therefore, your generalized entity is just company.
Speaker 1 (03:02):
Okay, I think I get it. It's kind of like
those those labeled tepperware containers in your fridge.
Speaker 2 (03:07):
Oh I like that analogy.
Speaker 1 (03:08):
Yeah, Like you wouldn't take a sharpie and permanently right
last Tuesday spaghetti on the plastics, right, because if you
do that, the container is completely useless When you make
chicken next week.
Speaker 2 (03:18):
Yeah, you'd have to throw it out or cross it.
Speaker 1 (03:19):
Out, right. Instead, you label it pasta or just leftovers.
That generic label is your entity. That way your system
can handle whatever specific meal you decide to put inside
it tomorrow.
Speaker 2 (03:31):
That is a perfect way to look at it. Future
proofing your software depends entirely on that kind of generalization.
By creating that generic company container, your system can scale infinitely.
You can track any publicly traded company without ever having
to rewrite the foundational rules of your app.
Speaker 1 (03:48):
Makes total sense.
Speaker 2 (03:49):
And just to keep things uniform, software architects follow strict
naming conventions for entities. We always use the singular form,
and we use camel case, So no spaces, right, no spaces,
and you capitalize the first letter of each word, so
capital C company.
Speaker 1 (04:04):
Okay, so we've got our first container. The next question
we have to ask ourselves is what other kind of
information needs its own box? Like we want to track
daily stock values, right, so would our second entity just
be stock price? Capital S, capital P, no spaces.
Speaker 2 (04:19):
You nailed it, But right now those are just empty boxes.
To make them actually useful, we have to characterize them.
We need to give them attributes.
Speaker 1 (04:26):
Okay, attributes, So those are like the defining characteristics.
Speaker 2 (04:29):
Of the entity exactly. So for our company entity, a
pretty essential attribute would be its name, and we'd probably
also want its ticker symbol.
Speaker 1 (04:37):
Got it? And is there a naming rule for those two?
Speaker 2 (04:40):
There is? For attributes, we use snake case, so it's
all lowercase, and we use underscores instead of spaces, so
ticker symbol is written ticker underscore symbol.
Speaker 1 (04:49):
Okay, So snake case with the attributes inside the box
camel case for the box itself, you got it. And
for our stock price entity, the obvious attributes would be
the actual price. Maybe the data was recorded something like
capshured at.
Speaker 2 (05:02):
Perfect Yes, But identifying the attributes is really just scratching
the surface here, because we can't just throw raw data
into these tupperware containers randomly.
Speaker 1 (05:11):
We can't.
Speaker 2 (05:12):
Now we have to declare exactly what kind of data
each attribute is allowed to hold.
Speaker 1 (05:17):
Ah. Okay, this brings us back to that multimillion dollar
crash I mentioned at the very.
Speaker 2 (05:21):
Beginning, doesn't it absolutely does. Look, databases aren't just digital
filing cabinets where you shove loose paper. They are incredibly
rigid math and slowing engines, right, right. So if you
tell a database to calculate the average stock price for
the year, and somewhere in those thousands of records, someone
typed the word three, like literally spelled out three instead
(05:44):
of the number three.
Speaker 1 (05:45):
The math inj she just throws it hands up exactly.
Speaker 2 (05:48):
Cannot compute it. It panics, and the whole thing crashes.
So to prevent that, we assign very strict data types
to every single attribute.
Speaker 1 (05:55):
Okay, let's run through this menu of constraints then, and
I want to stick with our tupperware analogy, go for it.
So first we have the string data type. Now, this
is for alphanumeric characters, so letters, number, symbols, whatever. Yeah,
I imagine this is like your standard medium sized tupperware.
It's flexible and it's perfect for holding a company name
or a ticker symbol.
Speaker 2 (06:13):
That's a great fit. Then you have the integer data type.
Now this is strictly for whole numbers positive or negative
doesn't matter, but absolutely no decimals.
Speaker 1 (06:22):
Okay, So an integer is basically a container with molded
slots specifically for whole eggs, Like you physically cannot force
half an egg into it.
Speaker 2 (06:30):
Yes, exactly.
Speaker 1 (06:31):
Well, wait for our stock price entity. The price attribute
needs dollars and cents. I mean, an intager isn't going
to work for a stock price of three hundred dollars
and fifty cents.
Speaker 2 (06:41):
It won't, which is why we use the decimal data
type instead. It is specifically engineered to handle numeric values
with high precision decimal places, and that is absolutely vital
for monetary values.
Speaker 1 (06:52):
Oh, because you don't want the computer rounding your money
incorrectly precisely.
Speaker 2 (06:56):
You might hear about other types like float or double
if you explore their languages, but decimal ensures the math
engine doesn't introduce weird rounding errors when it's calculating financial data.
Speaker 1 (07:07):
Okay, good to know. Then we also have the boolean
data type. That one is strictly true or false.
Speaker 2 (07:12):
Right, it's true or false.
Speaker 1 (07:13):
Yeah. So in our fridge analogy, this is that ultra
thin container specifically designed to hold exactly one slice of
American cheese.
Speaker 2 (07:21):
Wow. Yes, very specific, but yes, it's just highly optimized.
Speaker 1 (07:25):
It takes up the bare minimum amount of memory because
it only ever answers it yes or no question like
is the market open? True or false?
Speaker 2 (07:31):
Exactly. And we also use the text data type for
massive quantities of characters, like if you had a multipage
company history. And finally, the date data type.
Speaker 1 (07:40):
Which would be perfect for our capture data attribute on.
Speaker 2 (07:43):
The stock price exactly because the database actually knows how
to chronologically sort dates rather than just reading them as
a random string of numbers.
Speaker 1 (07:51):
Okay, so we've got our data types. Yeah, and there
is one final crucial attribute that every entity just gets automatically, right,
the ID.
Speaker 2 (08:00):
Yes, the ID is a unique integer. The second you
put a record into the database, it just automatically gets
stamped with this unique barcode number.
Speaker 1 (08:09):
Okay, so stepping back, let's look at what we've built.
We have a box for companies and a box for
stock prices, and they both have really strict rules for
what goes inside them. They do, but right now they're
sitting on completely opposite sides of the room, totally ignoring
each other. Like, how does a floating price of three
hundred dollars know whose stock it actually belongs to?
Speaker 2 (08:30):
And this is where we start weaving the invisible threads.
We have to establish relationships.
Speaker 1 (08:34):
Okay, how do we do that?
Speaker 2 (08:35):
In our scenario, we're defining what we call a one
to many relationship. Think about it. A single company like
Tesler has many stock prices over its lifespan, right, a
new one every day exactly. But conversely, one single stock
price record belongs to one specific company. So to make
that structural link, we use something called a foreign key.
Speaker 1 (08:55):
A foreign key, okay, So we take that unique automatic
ID from the company record and we plant a reference
to it directly inside the stock price entity.
Speaker 2 (09:04):
Yes, you got it.
Speaker 1 (09:05):
Like, we literally create an attribute on the stock price
called companied. So if the database assigns Tesla an ID
of one, every single time we record a new daily
price for Tesla, we just stamp that price record with
a companied of one. Yep.
Speaker 2 (09:20):
And if Facebook gets ID two, all its prices get
stamped with a two.
Speaker 1 (09:24):
But hold on, you're losing me a bit here. Why
are we playing matching games with numbers?
Speaker 2 (09:28):
What do you mean?
Speaker 1 (09:29):
Well, if you're listening to this, you're probably wondering, why
not just add an attribute called company name directly to
the stock price and just take the word Tesla every time.
I mean, it feels way less complicated to just read
the name instead of cross referencing numbers.
Speaker 2 (09:42):
I get that, and Honestly, it is the most common
temptation for beginners, but it inevitably leads to disaster. Really why,
because a concept called data normalization. Let's imagine you take
the easy route. You hardcode the string Tesla into say,
ten thousand daily stock records. Okay, seems fine so far,
but then tomorrow Tesla decides to rebrand. They change their
(10:03):
corporate name entirely.
Speaker 1 (10:04):
Oh wow. Yeah, if I hard coded the name, I
suddenly have a massive problem.
Speaker 2 (10:08):
A huge problem. You would have to search through ten
thousand individual stock records and update that exact string of
text manually, and if you miss even one.
Speaker 1 (10:18):
My financial reports are completely fractured.
Speaker 2 (10:20):
Exactly. But by linking everything to a single company ID instead,
the name Tesla only actually exists in one single place
in your entire.
Speaker 1 (10:30):
Architecture, inside the company record with ID one.
Speaker 2 (10:32):
Yes, those ten thousand stock prices, they don't care what
the company is called. They just point to ID one.
So if the company changes its name, you just updated
exactly once in that root container.
Speaker 1 (10:42):
Well that's brilliant. So it's basically a cascading update. I
changed it at the root level, and all ten thousand
branches instantly reflect the new reality because the mathematical relationship
is what remains intact exactly.
Speaker 2 (10:54):
It saves hours of work, it completely eliminates human error,
and it creates what we call a single source of truth.
Speaker 1 (11:01):
A single source of truth. I love that. Okay, so
we have our theory locked in, we have our blueprints,
but you know, blueprints don't keep the rain out. We
actually need to transition from these concepts into the would
be on RAILS framework. We need to build a house.
Speaker 2 (11:14):
Let's build it now.
Speaker 1 (11:15):
If you're listening to this and thinking, oh, I don't
know how to code, this is where I get lost,
take a breath. The code itself isn't the main focus here.
The point is actually understanding how much heavy lifting this framework.
Speaker 2 (11:26):
Does for you, because back in the day, translating these
blueprints meant writing hundreds of lines.
Speaker 1 (11:32):
Of raw sequel SEQL structured query language right.
Speaker 2 (11:35):
SEQL is the native tongue of databases, and it is
notoriously unforgiving. I mean, you miss one semicolon and nothing works.
Speaker 1 (11:43):
The RAILS changes the game, right because it uses something
called an OARM.
Speaker 2 (11:47):
Yes, object relational mapping, and the specific library that RAILS
uses for this is called active record.
Speaker 1 (11:53):
So how does that work.
Speaker 2 (11:54):
You can basically think of an OARM as a hyper efficient,
real time foreign language translator. On one side, you are
thinking and speaking in Ruby, which is a very intuitive
object oriented programming language. But on the other side is
the database and it's sitting there expecting these rigid SQL commands.
Active record just sits in the middle. It translates your
(12:16):
simple Ruby concepts perfectly into complex seqls, so you never
actually have to write it yourself.
Speaker 1 (12:21):
That is amazing. So let's see that translator in action.
Let's start with our independent entity, the company. In the
Rails command line. You just type a really simple instruction
Rails generate model company name dot string tick or symbol
dot string, and that's it.
Speaker 2 (12:38):
That's all it takes. And notice how we didn't mention
the ID in that command at all. Rails automatically handles
creating that unique barcode for us.
Speaker 1 (12:47):
So when you hit enter, what happens.
Speaker 2 (12:49):
Well, the framework acts like a massive engine. It generates
a bunch of files for you automatically. But two of
them are super critical for our data model, migration file
and the bottle file.
Speaker 1 (12:58):
Okay, so the migration file first, that's a Ruby script.
Speaker 2 (13:00):
Right, It contains the literal instructions to physically alter the
database architecture. It tells the system, hey, carve out a
new table called companies, and you'll notice it automatically pluralized
the name for the table.
Speaker 1 (13:12):
Because it's holding many companies. Makes sense. And then the
model file is a Ruby class file that represents the
singular concept company exactly.
Speaker 2 (13:21):
This is the object side of our translator. But it's
important to note just generating these files doesn't actually do
anything to the database yet.
Speaker 1 (13:29):
Right, we've basically just drawn up the work order exactly.
Speaker 2 (13:32):
To execute those work orders, you have to run another
command rails dB dot migrate.
Speaker 1 (13:38):
Oh.
Speaker 2 (13:38):
That command looks at your migration script, translates it into
a gnarly SQL create table command and physically builds the structure.
It also updates a master document called schema dot rb.
Speaker 1 (13:50):
Okay, I have to stop you there, because whenever I
hear developers talk about the schema file, it's always with
this mix of like reverence and absolutely fear.
Speaker 2 (14:00):
Oh for good reason.
Speaker 1 (14:01):
It's essentially the ultimate map of your entire database. It
shows every table, every column that actually exists, but there
is a massive warning label on it. Never open it
and type in it directly.
Speaker 2 (14:11):
Yeah, modifying schema dot RB by hand is a recipe
for catastrophic desynchronization.
Speaker 1 (14:17):
Catastrophic desynchronization. Yeah, that sounds bad.
Speaker 2 (14:20):
It is because if you bypass the migration files and
just type directly into the schema, your Rail's application thinks
the database looks one way, but the actual database engine
behaves a completely different way. It's a mess. Always always
use the Rails dB dot migrate command to orchestrate changes securely.
Speaker 1 (14:39):
Step away from the schema. Got it. Okay, okay, so
the company's table is officially built. Now we have to
tackle the stock price table. So we type rails generate
model stockprice price dot decimal, capture date dot date perfect. Wait,
how do we handle that invisible thread we talked about?
Do we just type company dot integer to manually create
(14:59):
that foreign key?
Speaker 2 (15:00):
I mean, you certainly could do it that way, but
Rails actually offers a really brilliant shortcut that just proves
the power of the framework. Instead of manually declaring an
integer field, you simply type company dot references.
Speaker 1 (15:12):
Just the word references. That does all the heavy lifting.
Speaker 2 (15:14):
It does. It acts as its own special data type.
In this context, when the generator sees the word references,
it dynamically looks for a model named company. It then
automatically creates the companied integer column for you, and crucially,
it writes all the complex sequel constraints into the database
to ensure that the foreign key is secure and properly
indexed for fast searching. You just run Rails dB dot
(15:37):
migrate again and your entire relational architecture is brought to life.
Speaker 1 (15:41):
That is so cool. Okay, so we have the house,
the tables exist, the strict rules are applied, and the
relationships are mathematically sound. But you know, a database without
data is really just an expensive, empty filing cabinet.
Speaker 2 (15:54):
Very true.
Speaker 1 (15:55):
We need to step into the control room and prove
that this architecture actually works.
Speaker 2 (15:58):
And this is exactly where the Rails console comes in.
Speaker 1 (16:01):
The Rails console.
Speaker 2 (16:02):
Yeah. By just typing Rails console in your terminal, you
drop right into a sandbox environment. It lets you interact
with your database using pure Ruby. You can test out
all your models and relationships before you ever even worry
about building a user interface or web pages.
Speaker 1 (16:16):
Okay, so we're in the sandbox. Let's create our very
first piece of data. I type a variable let's call
it C and I set an equal to company dot new.
I give it the name Tesla and the ticker symbol TSLA.
Speaker 2 (16:29):
Okay, But at this exact moment, is it in the database.
Speaker 1 (16:31):
No, right, it's just sort of hovering in the applications
temporary memory.
Speaker 2 (16:36):
Exactly. It exists only in the memory of your current session.
If you close the console right then it just vanishes.
To persist that data, To permanently write it into the
hard drive of the database, you have to call an
instance method on that object. You type C dot.
Speaker 1 (16:51):
Save, And this is where the magic really clicks for me.
You hit enter on dot save and you don't touch
a spreadsheet. You don't have to write some crazy SEQL
insert statement. Yep. The active record or m grabs that
hovering object, translates it into database language securely, ejects it
into the company's table, and instantly kicks back at assigned
idea of one. It just wove your concept into a
(17:12):
permanent reality.
Speaker 2 (17:13):
It really is satisfying, and the power of that abstraction
becomes even more obvious when we start dealing with our relationships.
Let's create a stock price. Now, we start by initializing
a new one pg'al khiel stockprice Dot new and we
give it a price of say five hundred dollars in
a date. Okay, now we need to link it to Tesla.
And remember, we don't want to play matching games with
integer ideas if we don't have to.
Speaker 1 (17:35):
Right, Because in our actual RAILS model files we use
those keywords belongs to Dot company and has many Dot
stock prices, we explicitly told the translator how they relate.
Speaker 2 (17:47):
To each other exactly. And because you declared that relationship,
RAILS allows you to simply pass the actual company object.
That variable C we just saved directly to the stock price.
Speaker 1 (17:56):
You don't pass the number one, you pass the whole variable.
Speaker 2 (17:58):
We passed the whole object. The OORM looks at it, intelligently,
extracts the primary key idea of one out of it,
and slots it perfectly into the companied foreign key column.
Then you hit P save and the invisible thread is
permanently secured in the database.
Speaker 1 (18:13):
That is wild. It is abstracting away all that tedious
wiring and getting that data back out is just as intuitive, rightfinitely, Like,
if I want to see a history of Tesla stock prices,
I don't write a massive search query. I just take
my company variable C and I type c dot stock prices,
and the ORM just instantly fetches an array containing every
single related stock price object.
Speaker 2 (18:33):
It's basically magic, and you can manipulate existing data with
the exact same ease. Say Tesla decides to shorten its
ticker symbol to just TLA, you don't have to create
a new record.
Speaker 1 (18:44):
What do you do?
Speaker 2 (18:44):
You just grab the existing object and use the dot
update method and you pass in the new string. The
ORM builds in SQL update query behind the scenes and
just executes it instantly.
Speaker 1 (18:56):
What if a company goes completely bankrupt and we want
to like purge it for our system entirely, do we
have to manually delete every single daily stock price first
so it doesn't crash?
Speaker 2 (19:06):
Not at all. You have very powerful destructive methods at
your disposal. You can call dot destroy on a specific record,
and depending on how you configured your hasmini relationship earlier,
you can actually tell rails that if a company is destroyed,
it should automatically cascade down and destroy all associated stock prices.
Speaker 1 (19:23):
Oh, so you don't end up with a bunch of
orson data floating in the voice exactly.
Speaker 2 (19:27):
It cleans up after itself.
Speaker 1 (19:28):
So with just a few intuitive English like commands like
dot save, dot update, dot destroy, we are commanding a massive,
complex mathematical engine securely.
Speaker 2 (19:38):
Yeah, the sheer complexity of SEQL, the rigidness of the
database tables, it's all abstracted away. The framework allows you
to focus purely on the logic of your real world
problem instead of fighting the syntax.
Speaker 1 (19:50):
Okay, left, take a breath and look at the terrain
we've covered today. We started with the chaotic idea of
tracking fluctuating stocks. We learned that the first defense against
catastrophic failure is generalizing those specific concepts into entities like
company and stock price. Right, we gave them attributes, and
we constrain them with strict data types, treating the database
(20:12):
as a math engine rather than just a filing cabinet.
We wired them together using the one to many relationship
and foreign keys to create a single source.
Speaker 2 (20:20):
Of truth, which is so important.
Speaker 1 (20:22):
And finally, we use the RAILS framework and its active
record OARM to effortlessly translate those blueprints into a fully functioning,
queriable data ecosystem.
Speaker 2 (20:31):
You have officially moved from abstract thought to designing concrete
information architecture.
Speaker 1 (20:37):
Absolutely so to everyone listening right now, we want to
leave you with a quick thought exercise, just to test
your new software architect mindset.
Speaker 2 (20:44):
I love a good thought exercise.
Speaker 1 (20:46):
Let's say you decide your financial tracker needs to include
the CEO of each company based on the rules of
generalization and data normalization we discussed today, how would you
build it? Good question? Should CEO just be a simple
string attribute added directly to the existing company container, or
should CEO be its own, completely separate entity that gets
(21:07):
linked via a foreign key? Right, ask yourself what happens
to your data if a CEO steps down and a
new one takes over, and you want to preserve the
history of who was exactly in charge when a specific stockspiked.
Speaker 2 (21:21):
That scenario is the ultimate test of finding the right
level of normalization for your app. And you know, as
you go about your day, I'd really encourage you to
start looking at the digital world differently. What do you
mean next time you open a shopping app or you're
just scrolling through social media, try to look past the
flashy photos and the polished user interface. Try to actually
spot the invisible architecture. Look for the entities try to
(21:44):
guess what the attributes are, well, it's fine, yeah. Imagine
the hidden foreign keys that are secretly binding that entire
digital universe together.
Speaker 1 (21:52):
Behind the screen, it is all just carefully defined containers
in visible threads. Suddenly, that infinitely comeplay software doesn't look
like magic anymore. It's just an architecture waiting for you
to define the rules.
So back in twenty fourteen, there was this massive international
corporation that ended up losing like millions of dollars in
a single afternoon.
Speaker 2 (00:08):
Oh yeah, I know exactly what you're talking about, the
ultimate night mercenario, right.
Speaker 1 (00:11):
And the crazy thing is it wasn't a market crash,
It wasn't you know, a bad investment strategy or anything.
It was a complete system failure caused by a single
word spelled wrong in a database.
Speaker 2 (00:23):
Millions of rows of data, all brought down by one typo.
Speaker 1 (00:26):
Yeah exactly. Someone basically just typed a plain text name
in a field that was expecting something else, and the
entire math engine behind the company's software just it completely
folded in on itself.
Speaker 2 (00:38):
Which is terrifying, honestly, because that usually happens when people
try to take the messy, infinite complexity of the real
world and just kind of cram it into a computer
without setting up rigid rules first, right.
Speaker 1 (00:50):
Which brings us to our mission for today's deep dive.
We're going to talk about the invisible structures that prevent
that exact kind of catastrophe. So imagine for a second
that you are listener, want to build your own personal
financial tracking system.
Speaker 2 (01:04):
Okay, I like where this is going.
Speaker 1 (01:06):
Yeah, so you want to track historical stock prices. Say
you start with Tesla because you want to run some analysis,
but you know you're ambitious. You know you might want
to add Facebook or Google or literally any other company
down the line. Right, You need flexibility exactly, So how
do you translate that real world goal into a clean,
functioning digital system. Today we are driving deep into data modeling. Specifically,
(01:31):
we're going to take a conceptual idea and bring it
to life using a framework called Rubyon.
Speaker 2 (01:36):
Rails, which is such an incredibly powerful tool for this,
it really is.
Speaker 1 (01:40):
So we're going to break the world down into what
we call entities, link them all together, and seamlessly translate
them into a living database. By the end of this
deep dive, you're going to understand the hidden architecture powering
the apps you use every single day.
Speaker 2 (01:54):
And honestly, the best part about this whole process is
that the very first step of building you know, atproof system,
it actually has absolutely nothing to do with writing.
Speaker 1 (02:03):
Code, well really no code at all.
Speaker 2 (02:05):
Zero code. Before you even touch a keyboard. You have
to look at your overarching goal, in this case, tracking stocks,
and you just start isolating the mounds in your story.
You have to identify the entities.
Speaker 1 (02:16):
Okay, So an entity is just what a generic concept
that represents a real world thing.
Speaker 2 (02:21):
Exactly, It's a generalized Now.
Speaker 1 (02:23):
Okay, well, if I look at my financial tracker, my
first instinct is just to say, well, Tesla is the
main player here. So Tesla is my first entity.
Speaker 2 (02:32):
And see that instinct right there? That is exactly what
backs early developers into a massive corner. Really, how so,
because Tesla is just one specific instance of a thing.
If you create an entity and actually name it Tesla,
you've hard coded your entire system to only ever understand
that one single business.
Speaker 1 (02:51):
Oh I see right.
Speaker 2 (02:52):
So the key to data modeling is stepping back and asking,
what is Tesla a type of Ah?
Speaker 1 (02:57):
Okay, it's a company.
Speaker 2 (02:58):
Exactly, it's a company. Therefore, your generalized entity is just company.
Speaker 1 (03:02):
Okay, I think I get it. It's kind of like
those those labeled tepperware containers in your fridge.
Speaker 2 (03:07):
Oh I like that analogy.
Speaker 1 (03:08):
Yeah, Like you wouldn't take a sharpie and permanently right
last Tuesday spaghetti on the plastics, right, because if you
do that, the container is completely useless When you make
chicken next week.
Speaker 2 (03:18):
Yeah, you'd have to throw it out or cross it.
Speaker 1 (03:19):
Out, right. Instead, you label it pasta or just leftovers.
That generic label is your entity. That way your system
can handle whatever specific meal you decide to put inside
it tomorrow.
Speaker 2 (03:31):
That is a perfect way to look at it. Future
proofing your software depends entirely on that kind of generalization.
By creating that generic company container, your system can scale infinitely.
You can track any publicly traded company without ever having
to rewrite the foundational rules of your app.
Speaker 1 (03:48):
Makes total sense.
Speaker 2 (03:49):
And just to keep things uniform, software architects follow strict
naming conventions for entities. We always use the singular form,
and we use camel case, So no spaces, right, no spaces,
and you capitalize the first letter of each word, so
capital C company.
Speaker 1 (04:04):
Okay, so we've got our first container. The next question
we have to ask ourselves is what other kind of
information needs its own box? Like we want to track
daily stock values, right, so would our second entity just
be stock price? Capital S, capital P, no spaces.
Speaker 2 (04:19):
You nailed it, But right now those are just empty boxes.
To make them actually useful, we have to characterize them.
We need to give them attributes.
Speaker 1 (04:26):
Okay, attributes, So those are like the defining characteristics.
Speaker 2 (04:29):
Of the entity exactly. So for our company entity, a
pretty essential attribute would be its name, and we'd probably
also want its ticker symbol.
Speaker 1 (04:37):
Got it? And is there a naming rule for those two?
Speaker 2 (04:40):
There is? For attributes, we use snake case, so it's
all lowercase, and we use underscores instead of spaces, so
ticker symbol is written ticker underscore symbol.
Speaker 1 (04:49):
Okay, So snake case with the attributes inside the box
camel case for the box itself, you got it. And
for our stock price entity, the obvious attributes would be
the actual price. Maybe the data was recorded something like
capshured at.
Speaker 2 (05:02):
Perfect Yes, But identifying the attributes is really just scratching
the surface here, because we can't just throw raw data
into these tupperware containers randomly.
Speaker 1 (05:11):
We can't.
Speaker 2 (05:12):
Now we have to declare exactly what kind of data
each attribute is allowed to hold.
Speaker 1 (05:17):
Ah. Okay, this brings us back to that multimillion dollar
crash I mentioned at the very.
Speaker 2 (05:21):
Beginning, doesn't it absolutely does. Look, databases aren't just digital
filing cabinets where you shove loose paper. They are incredibly
rigid math and slowing engines, right, right. So if you
tell a database to calculate the average stock price for
the year, and somewhere in those thousands of records, someone
typed the word three, like literally spelled out three instead
(05:44):
of the number three.
Speaker 1 (05:45):
The math inj she just throws it hands up exactly.
Speaker 2 (05:48):
Cannot compute it. It panics, and the whole thing crashes.
So to prevent that, we assign very strict data types
to every single attribute.
Speaker 1 (05:55):
Okay, let's run through this menu of constraints then, and
I want to stick with our tupperware analogy, go for it.
So first we have the string data type. Now, this
is for alphanumeric characters, so letters, number, symbols, whatever. Yeah,
I imagine this is like your standard medium sized tupperware.
It's flexible and it's perfect for holding a company name
or a ticker symbol.
Speaker 2 (06:13):
That's a great fit. Then you have the integer data type.
Now this is strictly for whole numbers positive or negative
doesn't matter, but absolutely no decimals.
Speaker 1 (06:22):
Okay, So an integer is basically a container with molded
slots specifically for whole eggs, Like you physically cannot force
half an egg into it.
Speaker 2 (06:30):
Yes, exactly.
Speaker 1 (06:31):
Well, wait for our stock price entity. The price attribute
needs dollars and cents. I mean, an intager isn't going
to work for a stock price of three hundred dollars
and fifty cents.
Speaker 2 (06:41):
It won't, which is why we use the decimal data
type instead. It is specifically engineered to handle numeric values
with high precision decimal places, and that is absolutely vital
for monetary values.
Speaker 1 (06:52):
Oh, because you don't want the computer rounding your money
incorrectly precisely.
Speaker 2 (06:56):
You might hear about other types like float or double
if you explore their languages, but decimal ensures the math
engine doesn't introduce weird rounding errors when it's calculating financial data.
Speaker 1 (07:07):
Okay, good to know. Then we also have the boolean
data type. That one is strictly true or false.
Speaker 2 (07:12):
Right, it's true or false.
Speaker 1 (07:13):
Yeah. So in our fridge analogy, this is that ultra
thin container specifically designed to hold exactly one slice of
American cheese.
Speaker 2 (07:21):
Wow. Yes, very specific, but yes, it's just highly optimized.
Speaker 1 (07:25):
It takes up the bare minimum amount of memory because
it only ever answers it yes or no question like
is the market open? True or false?
Speaker 2 (07:31):
Exactly. And we also use the text data type for
massive quantities of characters, like if you had a multipage
company history. And finally, the date data type.
Speaker 1 (07:40):
Which would be perfect for our capture data attribute on.
Speaker 2 (07:43):
The stock price exactly because the database actually knows how
to chronologically sort dates rather than just reading them as
a random string of numbers.
Speaker 1 (07:51):
Okay, so we've got our data types. Yeah, and there
is one final crucial attribute that every entity just gets automatically, right,
the ID.
Speaker 2 (08:00):
Yes, the ID is a unique integer. The second you
put a record into the database, it just automatically gets
stamped with this unique barcode number.
Speaker 1 (08:09):
Okay, so stepping back, let's look at what we've built.
We have a box for companies and a box for
stock prices, and they both have really strict rules for
what goes inside them. They do, but right now they're
sitting on completely opposite sides of the room, totally ignoring
each other. Like, how does a floating price of three
hundred dollars know whose stock it actually belongs to?
Speaker 2 (08:30):
And this is where we start weaving the invisible threads.
We have to establish relationships.
Speaker 1 (08:34):
Okay, how do we do that?
Speaker 2 (08:35):
In our scenario, we're defining what we call a one
to many relationship. Think about it. A single company like
Tesler has many stock prices over its lifespan, right, a
new one every day exactly. But conversely, one single stock
price record belongs to one specific company. So to make
that structural link, we use something called a foreign key.
Speaker 1 (08:55):
A foreign key, okay, So we take that unique automatic
ID from the company record and we plant a reference
to it directly inside the stock price entity.
Speaker 2 (09:04):
Yes, you got it.
Speaker 1 (09:05):
Like, we literally create an attribute on the stock price
called companied. So if the database assigns Tesla an ID
of one, every single time we record a new daily
price for Tesla, we just stamp that price record with
a companied of one. Yep.
Speaker 2 (09:20):
And if Facebook gets ID two, all its prices get
stamped with a two.
Speaker 1 (09:24):
But hold on, you're losing me a bit here. Why
are we playing matching games with numbers?
Speaker 2 (09:28):
What do you mean?
Speaker 1 (09:29):
Well, if you're listening to this, you're probably wondering, why
not just add an attribute called company name directly to
the stock price and just take the word Tesla every time.
I mean, it feels way less complicated to just read
the name instead of cross referencing numbers.
Speaker 2 (09:42):
I get that, and Honestly, it is the most common
temptation for beginners, but it inevitably leads to disaster. Really why,
because a concept called data normalization. Let's imagine you take
the easy route. You hardcode the string Tesla into say,
ten thousand daily stock records. Okay, seems fine so far,
but then tomorrow Tesla decides to rebrand. They change their
(10:03):
corporate name entirely.
Speaker 1 (10:04):
Oh wow. Yeah, if I hard coded the name, I
suddenly have a massive problem.
Speaker 2 (10:08):
A huge problem. You would have to search through ten
thousand individual stock records and update that exact string of
text manually, and if you miss even one.
Speaker 1 (10:18):
My financial reports are completely fractured.
Speaker 2 (10:20):
Exactly. But by linking everything to a single company ID instead,
the name Tesla only actually exists in one single place
in your entire.
Speaker 1 (10:30):
Architecture, inside the company record with ID one.
Speaker 2 (10:32):
Yes, those ten thousand stock prices, they don't care what
the company is called. They just point to ID one.
So if the company changes its name, you just updated
exactly once in that root container.
Speaker 1 (10:42):
Well that's brilliant. So it's basically a cascading update. I
changed it at the root level, and all ten thousand
branches instantly reflect the new reality because the mathematical relationship
is what remains intact exactly.
Speaker 2 (10:54):
It saves hours of work, it completely eliminates human error,
and it creates what we call a single source of truth.
Speaker 1 (11:01):
A single source of truth. I love that. Okay, so
we have our theory locked in, we have our blueprints,
but you know, blueprints don't keep the rain out. We
actually need to transition from these concepts into the would
be on RAILS framework. We need to build a house.
Speaker 2 (11:14):
Let's build it now.
Speaker 1 (11:15):
If you're listening to this and thinking, oh, I don't
know how to code, this is where I get lost,
take a breath. The code itself isn't the main focus here.
The point is actually understanding how much heavy lifting this framework.
Speaker 2 (11:26):
Does for you, because back in the day, translating these
blueprints meant writing hundreds of lines.
Speaker 1 (11:32):
Of raw sequel SEQL structured query language right.
Speaker 2 (11:35):
SEQL is the native tongue of databases, and it is
notoriously unforgiving. I mean, you miss one semicolon and nothing works.
Speaker 1 (11:43):
The RAILS changes the game, right because it uses something
called an OARM.
Speaker 2 (11:47):
Yes, object relational mapping, and the specific library that RAILS
uses for this is called active record.
Speaker 1 (11:53):
So how does that work.
Speaker 2 (11:54):
You can basically think of an OARM as a hyper efficient,
real time foreign language translator. On one side, you are
thinking and speaking in Ruby, which is a very intuitive
object oriented programming language. But on the other side is
the database and it's sitting there expecting these rigid SQL commands.
Active record just sits in the middle. It translates your
(12:16):
simple Ruby concepts perfectly into complex seqls, so you never
actually have to write it yourself.
Speaker 1 (12:21):
That is amazing. So let's see that translator in action.
Let's start with our independent entity, the company. In the
Rails command line. You just type a really simple instruction
Rails generate model company name dot string tick or symbol
dot string, and that's it.
Speaker 2 (12:38):
That's all it takes. And notice how we didn't mention
the ID in that command at all. Rails automatically handles
creating that unique barcode for us.
Speaker 1 (12:47):
So when you hit enter, what happens.
Speaker 2 (12:49):
Well, the framework acts like a massive engine. It generates
a bunch of files for you automatically. But two of
them are super critical for our data model, migration file
and the bottle file.
Speaker 1 (12:58):
Okay, so the migration file first, that's a Ruby script.
Speaker 2 (13:00):
Right, It contains the literal instructions to physically alter the
database architecture. It tells the system, hey, carve out a
new table called companies, and you'll notice it automatically pluralized
the name for the table.
Speaker 1 (13:12):
Because it's holding many companies. Makes sense. And then the
model file is a Ruby class file that represents the
singular concept company exactly.
Speaker 2 (13:21):
This is the object side of our translator. But it's
important to note just generating these files doesn't actually do
anything to the database yet.
Speaker 1 (13:29):
Right, we've basically just drawn up the work order exactly.
Speaker 2 (13:32):
To execute those work orders, you have to run another
command rails dB dot migrate.
Speaker 1 (13:38):
Oh.
Speaker 2 (13:38):
That command looks at your migration script, translates it into
a gnarly SQL create table command and physically builds the structure.
It also updates a master document called schema dot rb.
Speaker 1 (13:50):
Okay, I have to stop you there, because whenever I
hear developers talk about the schema file, it's always with
this mix of like reverence and absolutely fear.
Speaker 2 (14:00):
Oh for good reason.
Speaker 1 (14:01):
It's essentially the ultimate map of your entire database. It
shows every table, every column that actually exists, but there
is a massive warning label on it. Never open it
and type in it directly.
Speaker 2 (14:11):
Yeah, modifying schema dot RB by hand is a recipe
for catastrophic desynchronization.
Speaker 1 (14:17):
Catastrophic desynchronization. Yeah, that sounds bad.
Speaker 2 (14:20):
It is because if you bypass the migration files and
just type directly into the schema, your Rail's application thinks
the database looks one way, but the actual database engine
behaves a completely different way. It's a mess. Always always
use the Rails dB dot migrate command to orchestrate changes securely.
Speaker 1 (14:39):
Step away from the schema. Got it. Okay, okay, so
the company's table is officially built. Now we have to
tackle the stock price table. So we type rails generate
model stockprice price dot decimal, capture date dot date perfect. Wait,
how do we handle that invisible thread we talked about?
Do we just type company dot integer to manually create
(14:59):
that foreign key?
Speaker 2 (15:00):
I mean, you certainly could do it that way, but
Rails actually offers a really brilliant shortcut that just proves
the power of the framework. Instead of manually declaring an
integer field, you simply type company dot references.
Speaker 1 (15:12):
Just the word references. That does all the heavy lifting.
Speaker 2 (15:14):
It does. It acts as its own special data type.
In this context, when the generator sees the word references,
it dynamically looks for a model named company. It then
automatically creates the companied integer column for you, and crucially,
it writes all the complex sequel constraints into the database
to ensure that the foreign key is secure and properly
indexed for fast searching. You just run Rails dB dot
(15:37):
migrate again and your entire relational architecture is brought to life.
Speaker 1 (15:41):
That is so cool. Okay, so we have the house,
the tables exist, the strict rules are applied, and the
relationships are mathematically sound. But you know, a database without
data is really just an expensive, empty filing cabinet.
Speaker 2 (15:54):
Very true.
Speaker 1 (15:55):
We need to step into the control room and prove
that this architecture actually works.
Speaker 2 (15:58):
And this is exactly where the Rails console comes in.
Speaker 1 (16:01):
The Rails console.
Speaker 2 (16:02):
Yeah. By just typing Rails console in your terminal, you
drop right into a sandbox environment. It lets you interact
with your database using pure Ruby. You can test out
all your models and relationships before you ever even worry
about building a user interface or web pages.
Speaker 1 (16:16):
Okay, so we're in the sandbox. Let's create our very
first piece of data. I type a variable let's call
it C and I set an equal to company dot new.
I give it the name Tesla and the ticker symbol TSLA.
Speaker 2 (16:29):
Okay, But at this exact moment, is it in the database.
Speaker 1 (16:31):
No, right, it's just sort of hovering in the applications
temporary memory.
Speaker 2 (16:36):
Exactly. It exists only in the memory of your current session.
If you close the console right then it just vanishes.
To persist that data, To permanently write it into the
hard drive of the database, you have to call an
instance method on that object. You type C dot.
Speaker 1 (16:51):
Save, And this is where the magic really clicks for me.
You hit enter on dot save and you don't touch
a spreadsheet. You don't have to write some crazy SEQL
insert statement. Yep. The active record or m grabs that
hovering object, translates it into database language securely, ejects it
into the company's table, and instantly kicks back at assigned
idea of one. It just wove your concept into a
(17:12):
permanent reality.
Speaker 2 (17:13):
It really is satisfying, and the power of that abstraction
becomes even more obvious when we start dealing with our relationships.
Let's create a stock price. Now, we start by initializing
a new one pg'al khiel stockprice Dot new and we
give it a price of say five hundred dollars in
a date. Okay, now we need to link it to Tesla.
And remember, we don't want to play matching games with
integer ideas if we don't have to.
Speaker 1 (17:35):
Right, Because in our actual RAILS model files we use
those keywords belongs to Dot company and has many Dot
stock prices, we explicitly told the translator how they relate.
Speaker 2 (17:47):
To each other exactly. And because you declared that relationship,
RAILS allows you to simply pass the actual company object.
That variable C we just saved directly to the stock price.
Speaker 1 (17:56):
You don't pass the number one, you pass the whole variable.
Speaker 2 (17:58):
We passed the whole object. The OORM looks at it, intelligently,
extracts the primary key idea of one out of it,
and slots it perfectly into the companied foreign key column.
Then you hit P save and the invisible thread is
permanently secured in the database.
Speaker 1 (18:13):
That is wild. It is abstracting away all that tedious
wiring and getting that data back out is just as intuitive, rightfinitely, Like,
if I want to see a history of Tesla stock prices,
I don't write a massive search query. I just take
my company variable C and I type c dot stock prices,
and the ORM just instantly fetches an array containing every
single related stock price object.
Speaker 2 (18:33):
It's basically magic, and you can manipulate existing data with
the exact same ease. Say Tesla decides to shorten its
ticker symbol to just TLA, you don't have to create
a new record.
Speaker 1 (18:44):
What do you do?
Speaker 2 (18:44):
You just grab the existing object and use the dot
update method and you pass in the new string. The
ORM builds in SQL update query behind the scenes and
just executes it instantly.
Speaker 1 (18:56):
What if a company goes completely bankrupt and we want
to like purge it for our system entirely, do we
have to manually delete every single daily stock price first
so it doesn't crash?
Speaker 2 (19:06):
Not at all. You have very powerful destructive methods at
your disposal. You can call dot destroy on a specific record,
and depending on how you configured your hasmini relationship earlier,
you can actually tell rails that if a company is destroyed,
it should automatically cascade down and destroy all associated stock prices.
Speaker 1 (19:23):
Oh, so you don't end up with a bunch of
orson data floating in the voice exactly.
Speaker 2 (19:27):
It cleans up after itself.
Speaker 1 (19:28):
So with just a few intuitive English like commands like
dot save, dot update, dot destroy, we are commanding a massive,
complex mathematical engine securely.
Speaker 2 (19:38):
Yeah, the sheer complexity of SEQL, the rigidness of the
database tables, it's all abstracted away. The framework allows you
to focus purely on the logic of your real world
problem instead of fighting the syntax.
Speaker 1 (19:50):
Okay, left, take a breath and look at the terrain
we've covered today. We started with the chaotic idea of
tracking fluctuating stocks. We learned that the first defense against
catastrophic failure is generalizing those specific concepts into entities like
company and stock price. Right, we gave them attributes, and
we constrain them with strict data types, treating the database
(20:12):
as a math engine rather than just a filing cabinet.
We wired them together using the one to many relationship
and foreign keys to create a single source.
Speaker 2 (20:20):
Of truth, which is so important.
Speaker 1 (20:22):
And finally, we use the RAILS framework and its active
record OARM to effortlessly translate those blueprints into a fully functioning,
queriable data ecosystem.
Speaker 2 (20:31):
You have officially moved from abstract thought to designing concrete
information architecture.
Speaker 1 (20:37):
Absolutely so to everyone listening right now, we want to
leave you with a quick thought exercise, just to test
your new software architect mindset.
Speaker 2 (20:44):
I love a good thought exercise.
Speaker 1 (20:46):
Let's say you decide your financial tracker needs to include
the CEO of each company based on the rules of
generalization and data normalization we discussed today, how would you
build it? Good question? Should CEO just be a simple
string attribute added directly to the existing company container, or
should CEO be its own, completely separate entity that gets
(21:07):
linked via a foreign key? Right, ask yourself what happens
to your data if a CEO steps down and a
new one takes over, and you want to preserve the
history of who was exactly in charge when a specific stockspiked.
Speaker 2 (21:21):
That scenario is the ultimate test of finding the right
level of normalization for your app. And you know, as
you go about your day, I'd really encourage you to
start looking at the digital world differently. What do you
mean next time you open a shopping app or you're
just scrolling through social media, try to look past the
flashy photos and the polished user interface. Try to actually
spot the invisible architecture. Look for the entities try to
(21:44):
guess what the attributes are, well, it's fine, yeah. Imagine
the hidden foreign keys that are secretly binding that entire
digital universe together.
Speaker 1 (21:52):
Behind the screen, it is all just carefully defined containers
in visible threads. Suddenly, that infinitely comeplay software doesn't look
like magic anymore. It's just an architecture waiting for you
to define the rules.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
iHeartRadio 24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.