►
From YouTube: Database Office Hours - 2020-02-27
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
B
B
C
Yeah,
so
I
was
recently
reviewing
in
Amara
where
there
was
a
concern
about
the
add
column
with
default
helper,
and
it
was
on
on
the
on
a
table
that
had
previously
had
an
incident
dealing
with
rename
column
concurrently
and
so
the
the
question
that
I
ended
up
really
considering
was
we
were
dealing
with
an
ADD
column
with
default
on
a
boolean
column,
and
so
the
the
original
way
that
the
mr
was
structured
was
we
weren't
going
to
be
adding
a
default
to
the
boolean
column
and
all
of
the
existing
records
were
going
to
just
remain
null.
C
B
B
At
the
other
hand,
I
seen
examples
and
I
also
had
one
before
regarding
to
to
larger
tables,
for
example
the
exact
it
was.
We
had
a
case
where
we
had
to
batch
update
the
one
of
the
field
to
eliminate
and
now
we'll
use
and
the
net
or
not
no
constraint,
and
it
was
totally
fine,
I
would
say
in
this
case
they
should
be
fine
using
at
column
V
default.
B
B
B
One
thing
we
can:
we
can
always
do
you
know
like
updating
three
million
records
during
this
deployment,
because
the
migration
dance
and
we
deployed
the
the
new
code
to
to
canary,
we
could
maybe
fit
better
better
on
migration
that
refused
existing
items.
You
know
to
eliminate
the
nos
and
then
the
migration,
but
we
when
we
disabled
the
Nollan
and
said
the
default
volume
has
to
be
just
a
small
amount
of
over
records,
would
be
a
bit
of.
You
have
been
safer
approach
at
least
the
depth.
What
deployment
would
be
would
be
reliably
faster.
B
C
C
And
then
I
have
the
second
question
as
well,
which
it
was
just
a
curiosity
as
I
was
reading
through
an
issue.
I
wasn't
sure
what
the
the
10k
environment
was
referring
to
you,
but-
and
it
looks
like
my
question-
has
been
answered
thanks
to
and
just
for
people
watching,
I
guess
it's,
the
ten
thousand
user
configuration
environment.
D
B
B
B
I
can
feel
it
some
of
your
details
and
we
wanted
to
make
it
like
a
markdown
friendly,
and
this
means
we
need
to
add
another
column
where
we
store
the
HTML
representation
of
the
bio
field,
and
this
I
started
like
it
sounded
to
me,
like
it's,
probably
not
the
best
place.
To
put
this
column
and
I
also
noticed
that
we
have
some
fields
that
are
absolutely
not
used
in
the
core
feature
set
of
the
application.
You
can
see
it
on
the
user's
profile,
as
you
can
see
it,
the
other
API.
B
You
can
see
it
when
you
hover
on
the
user's
name
on
the
on
the
UI,
which
makes
an
additional
HTTP
request,
and
my
idea
was
to
take
these
I've
seen
large
columns
out
of
the
users
table
and
move
it
to
somewhere
else.
Simply
these
are
large.
Things
will
string
fields
and
then
it's
no
limit
on
the
on
the
columns.
So
if
you
have
database
access,
you
can
easily
find
a
doctor
in
in
Texas,
because
there
are
a
few
spammers
who
are
trying
to
fill
that
these.
B
These
large
columns
with
crappy
data
and
I
also
found
the
record
by
the
organization,
was
like
200
kilobytes
log,
which,
if
this
cause
are
those
hands,
can
significantly
affect
the
performance
because
loading
one
user
he
might
need
to
Road
like
to
300
kilobytes
from
the
disk,
so
I
started
working
on
a
monomer.
That's
basically
a
background
migration
that
we
slowly
try
to
take
out
these
data
from
the
users
table
and
put
it
into
users.
User
data,
stable
and
yeah
I
still
work
in
progress
and
I'm
planning
to
use
a
trigger
for
that.
B
So
a
Paragon
migration
that
does
most
of
the
work
and
not
regather
ensures
that
the
two
favors
are
sync
so
the
first
employment
it
don't
have
to
touch
the
application
code
because
everything
works
as
today.
But
additionally,
we
will
save
the
data
in
an
extra
payable
and
later
on
and
things
of
looking
good.
B
We
can
eliminate
the
columns
from
the
insights
data
and,
of
course,
if
this
is
working
I
already
seen
in
the
schema
that
we
put
up
tons
of
configuration,
specific
fields
to
projects,
groups,
namespaces,
CI
related
tables,
and
we
could
maybe
make
a
practice
out
of
this
done.
Ok,
the
core
domain
object
should
like
stay
kind
of
clean,
just
important
stuff
and
any
additional
like
configuration
orders.
Small
details
could
go
to
a
DDS
table
or
reference
table
and
yeah
any
any
comment
on
that.
B
E
B
B
B
So
we
only
react
and
sync
data
than
the
actual
field
that
we
are
thinking
is
has
changed.
So
that
is
an
option
for
the
trigger
specification,
but
still
it
would
be
nice
to
see
the
performance,
impact
and
I
think
we
can.
We
can
easily
measure
this
I'm
not
super
easily,
but
it's
possible
via
database
lab,
because
you
can
just
give
a
bunch
of
signal
commands
and
and
measure
it.
B
F
I
had
a
comment
I,
you
know,
I
think
this
is
a
great
idea.
The
only
thing
that
I'm
a
little
unsure
about
is
like
a
name
user
details,
I'm,
not
really
sure
what
details
is
and
I
feel
like
that's
sort
of
like
a
little
bit,
maybe
have
like
a
grab-bag
name,
and
if
it
contains
profile
information,
maybe
it
should
just
be
called
like
user
profile,
something
your
user
profiles.
If
that's
the
intent,
I
think
it's
just
maybe
a
little
more
clear.
D
B
You
already
have
a
table
called
user
preferences
and
that's
like
your
what
kind
of
color
scheme
you
are
using
and
things
like
that
originally
I
wanted
to
put
it
there,
but
after
pointed
out
that
it's
probably
not
the
best
place,
because
it's
not
like
a
preference,
it's
more
like
a
detail
for
the
user
is
like
the
diode
military
world,
LinkedIn,
URL
and
locations
to
me
because
looks
okay
but
yeah
we
can.
We
can
think
about
another
one,
other
name,
maybe
user
profile.
D
Actually,
in
the
discussion,
I
think
there
are
some
other
non
profile,
things
which
are
in
users
table
which
are
not
used
a
lot,
and
that
was
right
in
your
original
intention
to
move
in
frequently
used
columns
to
you,
know,
user,
details
or
profiles.
So
if
you
make
it
profiles
now
like
what
patrick
said,
we
really
need
a
place.
To
put
you
know
a
lot
of
user
stuff
like.
Let
me
you
example,
I,
have
put
recently
a
column
in
the
user
preferences
table.
D
C
B
D
I,
don't
want
to
put
it
in
the
users
table
and
if
it's
user
profiles,
then
it
will
be
too
little
so
I
will
not
be
able
to
put
anywhere.
That
means.
I
will
need
to
create
a
Turk
table,
so
we
might
or
for
table
like
users,
user
profiles,
user
preferences
and
then
I
will
create.
Maybe
users
experiment
details
or
something
like
that
anyway,.
C
F
C
B
A
B
B
B
I
mean
we:
can
we
don't
have
a
crystal
ball
either
to
tell
the
future
that
a
in
the
future
we
might
be
able
to
might
need
to
sort
by
the
bio
field
sounds
stupid,
but
this
is
just
an
example
and
then
we
would
be
pretty
much
yeah.
It
wouldn't
work
pretty
well
because
then
you
have
to
join
an
additional
relation
and
then
sorting.
C
And
so
another
review
that
I
was
working
on
this
week
mentions
adding
or
how
adding
in
index
in
specific
cases
might
not
be
valid
for
self-managed
instances
and
I
found
that
a
little
odd
and
surprising
and
wasn't
really
sure
how
to
address
that,
and
so
I
was
mostly
curious.
If
this
is
something
that
ever
comes
up
commonly,
and
you
know,
if
there's
any
concerns
about
it,.
B
So
I'd
look
at
it
a
bit
and
I
see
in
Sean's
comment
about
about
the
date
and
then
it
all
had
a
decline
in.
So
it
seems
that
in
the
specific
case
we
might
have
dedicated
record
records
in
the
database,
so
we
might
not
be
able
to
create
the
unique
index,
but
on
the
application,
level
looks
like
always
redundant
first
service
template.
Is
that
correct?
That's.
A
So
I
shown
comments
and
other
things
two
things
one
is
a
are
in
a
new
validation
with
maybe
in
invalid
records
in
the
database.
We
need
to
resolve
that,
but
the
other
point
is
a
Allanon
index.
M
that,
maybe
is
only
relevant
for
combat,
maybe
is
not
relevant
that
index
for
them
self
host
installations,
because
you
know
maybe
they
are
used
in
the
data
in
a
different
way.
So
I
wasn't
place
also.
Fourth,
for
that
day
confirm
so
I'm
not
sure
exactly
a.
A
B
B
So
if
we
want
to
ensure
uniqueness,
we
have
to
ensure
uniqueness
even
on
the
surface,
if
instances
and
if
we
can
clean
the
potential
applications
up
without
basically
breaking
anything,
I
think
that's
what
we
should
do
before
before
I
think
adding
the
index
and
from
from
this
comment,
I
can
kind
of
see
that
it's
just
a
big
application,
migration.
What
we
have
to
do
so
eliminated
complicated
records
and
then
apply
apply
the
index
again.
I'm,
not
quite
familiar
with
the
services
table,
so
yeah.
D
D
Even
in
that
scenario,
we
try
to
have
the
schema
available
for
Community,
Edition,
Enterprise,
Edition
and
guitar
comb,
and
we
have
one
schema
like
we
have
a
lot
of
tables
make
no
sense
at
all
in
Enterprise
Edition
or
in
self-hosted,
and
we
still
stick
to
one
schema
and
multiple
code
branches,
so
I
think,
based
on
that,
we
should
have
one
schema.
If
you
have
two
or
three
old,
this
thing
will
face
in
the
future
other
you
know
branching
and
conditional
behavior,
which
may
make
things
worse.
B
B
We
often
make
the
mistake
to
you,
know,
make
these
polymorphic
associations
and
put
everything
into
one
database
turbulence
and
later
on,
realize
that
hey
this
on
the
short-term
sales
last
time,
because
that's
work
need
to
be
done,
but
on
the
longer-term
ensuring
consistency
yeah,
it
will
buy
back
so
I'm,
not
sure
at
the
current
use
case.
But
I'm
I
see
two
options
here,
find
a
way
to
to
clean
up
the
table
and
make
the
unique
index
or
dining
table
for
the
for
the
for
the
new
feature
but
yeah.
D
B
A
So
so,
for
me
the
parrot
is
replacing
is
a
holiday,
uniqueness,
validation
and
I
Steve,
say
hey.
We
have
to
add
unique
index
here
for
the
two
corners
with
make
sense
and
then
some
say:
okay,
maybe
we
have
to
be
more
careful
like
I'm
in
Texas,
and
that
part
is
the
part
that
is
surprising
to
me.
You
know
like
if
we
have
a
uniqueness,
a
relation
make
a
lot
of
sense
to
to
add
the
index.
In
any
case,
I
guess
right.
B
Yes,
if
you
have
a
uniqueness
validation
on
the
model,
you
want
to
basically
ensure
the
consistency
on
the
database
level.
Simply
the
application
level
check
is
not
enough,
because
we
have
multiple
instances
running
so
there
is
a
concurrency
issue
like
a
race
condition
and
also
performance.
So
if
you
have
a
large
table
find
what
the
race
validation
doesn't
on
that
in
the
course
IDs
check.
A
do.
I
have
this
record
in
the
database.
Yes,
no,
and
based
on
that
you
get
the
validation
message
and
on
a
large
table
without
an
index.
C
B
E
Everybody
have
a
nice
I,
just
noticed.
Albers
comment
from
sorry
from
a
previous
question
was
not
managed,
was
not
handled,
I,
think
about
using
triggers
or
stored
special
procedures
instead
of
active
record
callbacks
like
I.
Have
many
discussion
also
like
using
callbacks
instead
or
but
most
more,
not
not
using
callbacks,
but
was
using
service
services
so
I'm
not
sure.
If
do
we
have
opinions
on
using
callbacks
or
not,
or
is
it
more
a
back-end
thing
that
we
should
discuss
somewhere
else.
B
B
D
We
are
the
database
team
and
you
know
triggers
kind
of
his
kind
of
falls
in
our
Brianne,
so
we
want
to
use
it.
It
was
the
bacon
team.
Then
they
would
come
up
with
a
migration
and
call
back
based
solution.
I
think
if
the
approach
to
populate
user
details
makes
sense
the
way
you
do
the
trigger,
we
should
make
it
a
database
library
at
some
point
to
empower
other
they
can
engineers
to
do
it.
D
B
B
D
F
B
Yeah,
this
structure
sequel
opens
Pandora's
Box
right.
We
have
access
to
so
many
new
features
and
I
think
the
best
thing
we
can
do
is
lead
the
way
start
using
slowly
things
within
within
the
database
team.
So
we
know
what's
happening,
clearly,
communicate
and
document
our
our
approach.
There
is
another
one
going
on
about
about
making
the
not
null
checks
like
more
efficient,
using
check
constraints.
That's
something
we
are
kind
of
looking
at
to
you
know,
make
it
available.