Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
Showing posts with label bit. Show all posts
Showing posts with label bit. Show all posts
Thursday, March 29, 2012
Do SQL Server's developers even know what the datetime datatype is?
Just a bit of a rant here...
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
I've marveled for a long time that SQL Server developers chose to store
SQL Agent job history dates in in the sysjobhistory table as two
seperate columns in integer format instead of a single datetime column.
I mean come on.
Then today I discovered that the Windows 2003 Perfmon stores dates as
char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
Char (24) won't even do an explicit conversion to datetime. You have to
only grab the first 23 characters.
I think Bill G. needs to send around an internal memo reminding
everyone about the datetime data type.
/end rantI wish Gert had included some background on why this decision came about,
but otherwise a great resource:
http://www.sqldev.net/sqlagent/SQLAgentDateTime.htm
As for Perfmon, isn't it possible it was formatted to CHAR(24) because it
usually logs to a file, and the file needs to be understood by more systems
than just SQL Server?
<pshroads@.gmail.com> wrote in message
news:1164659681.627479.274240@.h54g2000cwb.googlegroups.com...
> Just a bit of a rant here...
> I've marveled for a long time that SQL Server developers chose to store
> SQL Agent job history dates in in the sysjobhistory table as two
> seperate columns in integer format instead of a single datetime column.
> I mean come on.
> Then today I discovered that the Windows 2003 Perfmon stores dates as
> char(24) when the data is logged to a SQL Server database. CHAR(24)?!?!
> Char (24) won't even do an explicit conversion to datetime. You have to
> only grab the first 23 characters.
> I think Bill G. needs to send around an internal memo reminding
> everyone about the datetime data type.
> /end rant
>
Tuesday, March 27, 2012
do indexed views slow down inserts
sql2l sp3
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?
A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
sql
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?
A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
sql
do indexed views slow down inserts
sql2l sp3
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
do indexed views slow down inserts
sql2l sp3
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
--
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
Im starting to do a bit of research on indexed views. On a
normal table, a clustered index slows down inserts. Is the
same true for a clustered indexed view? Will it slow down
inserts for the underlying table?A clustered index does not have to slow down inserts. If you understand how
clustered indexes work and choose the appropriate column(s) for the index
expression it can actually speed it up and certainly can make a difference
on selects. Since an Indexed view uses a clustered index it can have the
same properties. That said an indexed view is always going to be slower on
inserts than a straight table simply because of the extra data your dealing
with. Each time you do an insert, update or delete on the underlying table
it potentially has to populate and recalculate the indexed views data. How
much depends on several factors such as the table size and definition and
the hardware setup etc. However these losses may be offset by the gains
that you can achieve on the selects against an indexed view. Again it
depends but in general they are not ideal for situations where you have lots
of inserts.
--
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:428701c47326$2badabd0$a601280a@.phx.gbl...
> sql2l sp3
> Im starting to do a bit of research on indexed views. On a
> normal table, a clustered index slows down inserts. Is the
> same true for a clustered indexed view? Will it slow down
> inserts for the underlying table?
Subscribe to:
Posts (Atom)