|
Home > Archive > microsoft.public.cert.mcdba > February 2003 > cute troll
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Christopher Hance 2003-02-16, 6:24 pm |
| Well-read, even, with the reference to "paper tiger[s]," commonly attributed
to Chairman Mao of Communist China. And it meets the minimum grammatical
error requirement. Corrected: "When the database goes to hell and I can't
fix it, I'll say, 'But I am an MCDBA.'" I'll even concede that point for
those who "learn" solely from brain dumps. I'm a bit conceited that I passed
087/228/229 from experience, without "learning for the test," but I try to
understand the existential dilemma for those who don't have experience and
are trying to get it.
Now as for the last part:
real: well, there seems to be some demand for MSSQL skills in the "real"
world
relational: yep, it's got multiple tables, foreign keys, all kinds of joins
database: hmm, stores data in tables. Typical structure of a database.
management system: well, one can add/delete/update schema and data, manage
indexes, filegroups, et al. Seems to fit here too.
MSSQL seems to meet the qualifications for a "real rdbms." Granted it's a
little more intuitive than Oracle, with which a qualified DBA should
probably have some familiarity unless the job description specifically
states that there will never be any cross-vendor database interaction.
Still, there seems to be fluctuation as to which actually runs faster and/or
better on a given piece of hardware. And then there's DB2, the hardware for
which exceeds most small/medium-business IT budgets. And mysql, which was
still working on the enforced relationships part last I heard. So define
"real" for me.
I'm going to stop my intellectual analysis before the "real os" part. Odd
that someone with this attitude signs up to msnews.microsoft.com or bothers
visiting the online forums on the microsoft.com site.
Hmm, so does arguing semantics without resorting to insults qualify as
"feeding the troll?" I knew I would regret it when I left my flamethrower in
the car.
--
Chris Hance
"@m$Sucks.com" <""Quad\"@m$Sucks.com"> wrote in message
news:eP#gXrg1CHA.2532@TK2MSFTNGP11.phx.gbl...
> sounds great! Can't wait till I'm a paper tiger. When the database goes
> to hell and I can't fix it. I'll say, but I have an MCDBA.
>
> Learn a real rdbms on a real os
| |
| @m$Sucks.com 2003-02-16, 6:24 pm |
| Christopher Hance wrote:
> Well-read, even, with the reference to "paper tiger[s]," commonly attributed
> to Chairman Mao of Communist China. And it meets the minimum grammatical
> error requirement. Corrected: "When the database goes to hell and I can't
> fix it, I'll say, 'But I am an MCDBA.'" I'll even concede that point for
> those who "learn" solely from brain dumps. I'm a bit conceited that I passed
> 087/228/229 from experience, without "learning for the test," but I try to
> understand the existential dilemma for those who don't have experience and
> are trying to get it.
>
> Now as for the last part:
> real: well, there seems to be some demand for MSSQL skills in the "real"
> world
> relational: yep, it's got multiple tables, foreign keys, all kinds of joins
> database: hmm, stores data in tables. Typical structure of a database.
> management system: well, one can add/delete/update schema and data, manage
> indexes, filegroups, et al. Seems to fit here too.
>
> MSSQL seems to meet the qualifications for a "real rdbms." Granted it's a
> little more intuitive than Oracle, with which a qualified DBA should
> probably have some familiarity unless the job description specifically
> states that there will never be any cross-vendor database interaction.
> Still, there seems to be fluctuation as to which actually runs faster and/or
> better on a given piece of hardware. And then there's DB2, the hardware for
> which exceeds most small/medium-business IT budgets. And mysql, which was
> still working on the enforced relationships part last I heard. So define
> "real" for me.
>
> I'm going to stop my intellectual analysis before the "real os" part. Odd
> that someone with this attitude signs up to msnews.microsoft.com or bothers
> visiting the online forums on the microsoft.com site.
>
> Hmm, so does arguing semantics without resorting to insults qualify as
> "feeding the troll?" I knew I would regret it when I left my flamethrower in
> the car.
>
> --
> Chris Hance
>
> "@m$Sucks.com" <""Quad\"@m$Sucks.com"> wrote in message
> news:eP#gXrg1CHA.2532@TK2MSFTNGP11.phx.gbl...
>
>>sounds great! Can't wait till I'm a paper tiger. When the database goes
>>to hell and I can't fix it. I'll say, but I have an MCDBA.
>>
>>Learn a real rdbms on a real os
>
>
>
A real rdbms is one that doesn't bring the internet to its knees by
propogating a worm. Hope that answers your question. A real OS is one
that is available from more than one vendor on more than one hardware
platform.
| |
| Jeffrey W. Roach 2003-02-16, 7:23 pm |
| That real OS you talk about if memory serves me right, have had their share
of security glitches (remember the BIND DNS issue). The Internet Worm was
caused by Admins who didn't patch their servers, the same goes for 'nix
Admins. I know I get just as many Security Bullitins for my Linux Servers as
I do for my Windows Servers. Of course with the name you're posting with,
your opinon is already biased. And yes Linux and Unix are available from
multiple sources and available on multiple platforms, but MS still owns 90%
of the Desktop Market and around 40% of the Server Market so until the
'nixes learn to play nice, MS will have a secure future. By the way the shop
I work in has IBM DB2 running on a A/S400, Oracle running on a R/S6000, and
MS SQL running on Win2k ADV Server. Oh yeah we have a new app running on
MYSQL...
--
Jeffrey W. Roach
MCSE, MCSA, CNA, Network+, A+
"@m$Sucks.com" <""Quad\"@m$Sucks.com"> wrote in message
news:utDgReh1CHA.1928@TK2MSFTNGP10...
> Christopher Hance wrote:
> > Well-read, even, with the reference to "paper tiger[s]," commonly
attributed
> > to Chairman Mao of Communist China. And it meets the minimum
grammatical
> > error requirement. Corrected: "When the database goes to hell and I
can't
> > fix it, I'll say, 'But I am an MCDBA.'" I'll even concede that point for
> > those who "learn" solely from brain dumps. I'm a bit conceited that I
passed
> > 087/228/229 from experience, without "learning for the test," but I try
to
> > understand the existential dilemma for those who don't have experience
and
> > are trying to get it.
> >
> > Now as for the last part:
> > real: well, there seems to be some demand for MSSQL skills in the "real"
> > world
> > relational: yep, it's got multiple tables, foreign keys, all kinds of
joins
> > database: hmm, stores data in tables. Typical structure of a database.
> > management system: well, one can add/delete/update schema and data,
manage
> > indexes, filegroups, et al. Seems to fit here too.
> >
> > MSSQL seems to meet the qualifications for a "real rdbms." Granted it's
a
> > little more intuitive than Oracle, with which a qualified DBA should
> > probably have some familiarity unless the job description specifically
> > states that there will never be any cross-vendor database interaction.
> > Still, there seems to be fluctuation as to which actually runs faster
and/or
> > better on a given piece of hardware. And then there's DB2, the hardware
for
> > which exceeds most small/medium-business IT budgets. And mysql, which
was
> > still working on the enforced relationships part last I heard. So define
> > "real" for me.
> >
> > I'm going to stop my intellectual analysis before the "real os" part.
Odd
> > that someone with this attitude signs up to msnews.microsoft.com or
bothers
> > visiting the online forums on the microsoft.com site.
> >
> > Hmm, so does arguing semantics without resorting to insults qualify as
> > "feeding the troll?" I knew I would regret it when I left my
flamethrower in
> > the car.
> >
> > --
> > Chris Hance
> >
> > "@m$Sucks.com" <""Quad\"@m$Sucks.com"> wrote in message
> > news:eP#gXrg1CHA.2532@TK2MSFTNGP11.phx.gbl...
> >
> >>sounds great! Can't wait till I'm a paper tiger. When the database goes
> >>to hell and I can't fix it. I'll say, but I have an MCDBA.
> >>
> >>Learn a real rdbms on a real os
> >
> >
> >
> A real rdbms is one that doesn't bring the internet to its knees by
> propogating a worm. Hope that answers your question. A real OS is one
> that is available from more than one vendor on more than one hardware
> platform.
>
| |
| Alan Davis 2003-02-17, 2:23 am |
| >Oh yeah we have a new app running on
>MYSQL...
Insane.... It's been a while since I looked at mysql. Does it now
support transactions and does it's locking strategies go past applying
a single 'file lock' in order stop concurrent access?
| |
| Alan Davis 2003-02-17, 2:23 am |
| >A real rdbms is one that doesn't bring the internet to its knees by
>propogating a worm. Hope that answers your question. A real OS is one
>that is available from more than one vendor on more than one hardware
>platform.
The reason for the slammer was down to incompetent admins (they should
all have been fired by now!).
All software will have security holes in it, even good old Unix (I
remember when the sendmail issue first arose). However the biggest
problem is the amount of unskilled administrators involved with ms
products and os's. They think if they can use the mmc, they are guru
admins!
| |
| Danut 2003-02-17, 10:23 am |
|
"Alan Davis" <T> wrote in message
news:c2415v8plid34copcg3m4apn6
saaq53oph@4ax.com...
> >A real rdbms is one that doesn't bring the internet to its knees by
> >propogating a worm. Hope that answers your question. A real OS is one
> >that is available from more than one vendor on more than one hardware
> >platform.
>
> The reason for the slammer was down to incompetent admins (they should
> all have been fired by now!).
Who is going to fire them, incompetent managers?
> All software will have security holes in it, even good old Unix (I
> remember when the sendmail issue first arose). However the biggest
> problem is the amount of unskilled administrators involved with ms
> products and os's. They think if they can use the mmc, they are guru
> admins!
I totally agree. Imagine a company where the db admins do not know that the
multiple SQL server installations on multiple machines have different
service packs? What about an admin that uses cursors inside a trigger? And
SQL code without any kind of error handling? Who cares if the stored
procedure will rollback or commit?
Danut
| |
| Jacco Schalkwijk 2003-02-17, 10:23 am |
| "Danut" <danutzp1@hotmail.com> wrote in message
news:OdUAWpp1CHA.1752@TK2MSFTNGP10...
>
> "Alan Davis" <T> wrote in message
> news:c2415v8plid34copcg3m4apn6
saaq53oph@4ax.com...
> > >A real rdbms is one that doesn't bring the internet to its knees by
> > >propogating a worm. Hope that answers your question. A real OS is one
> > >that is available from more than one vendor on more than one hardware
> > >platform.
> >
> > The reason for the slammer was down to incompetent admins (they should
> > all have been fired by now!).
>
> Who is going to fire them, incompetent managers?
incompetent network admins actually, rather than dba's. You don't really
need to expose port 1434 for any reason at all. Read what Robert Graham has
to say about Slammer
(http://www.robertgraham.com/journal...sqlslammer.html) and specially
the claim that he is running his website on a Windows system that hasn't
been patched in 5 years, yet has never been hacked.
>
> > All software will have security holes in it, even good old Unix (I
> > remember when the sendmail issue first arose). However the biggest
> > problem is the amount of unskilled administrators involved with ms
> > products and os's. They think if they can use the mmc, they are guru
> > admins!
>
> I totally agree. Imagine a company where the db admins do not know that
the
> multiple SQL server installations on multiple machines have different
> service packs? What about an admin that uses cursors inside a trigger? And
> SQL code without any kind of error handling? Who cares if the stored
> procedure will rollback or commit?
>
Just subscribe to microsoft.public.sqlserver.programming and see how often
people come up with cursors/dynamic sql/non-normalised designs etc. It's
scary.....
> Danut
>
>
| |
|
| Mysql is decent enough for somthing you want to face the web if you don't
want to pay for an unlimited connection to sql server, IF the database is
used to read data from. If you are doing transactions in it, forget it.
Mysql was designed with one thing in mind - speed, not data integrity, not
features, nothing else. Lotsa porn sites use it, or it could be used as an
online inventory for a website, just don't trust it for order taking.
"Alan Davis" <T> wrote in message
news:5t315v8kr7q41pgokiv3ja30t
c17ag438j@4ax.com...
> >Oh yeah we have a new app running on
> >MYSQL...
>
> Insane.... It's been a while since I looked at mysql. Does it now
> support transactions and does it's locking strategies go past applying
> a single 'file lock' in order stop concurrent access?
| |
| Alan Davis 2003-02-17, 11:23 am |
| X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: microsoft.public.cert.mcdba
NNTP-Posting-Host: host62-7-149-46.webport.bt.net 62.7.149.46
Path: TK2MSFTNGP08!TK2MSFTNGP12
Lines: 1
Xref: TK2MSFTNGP08 microsoft.public.cert.mcdba:4902
>incompetent network admins actually, rather than dba's. You don't really
>need to expose port 1434 for any reason at all
Exactly, who said anything about dba's?
>Just subscribe to microsoft.public.sqlserver.programming and see how often
>people come up with cursors/dynamic sql/non-normalised designs etc. It's
>scary.....
Not quite - it is VERY scary!
| |
| Jeffrey W. Roach 2003-02-17, 11:23 am |
| I'm not sure, its a turnkey solution that our Fire Department and GIS
Department bought for reverse 911, the company uses a dial-in to maintain
it, which is fine because of Davis' budget cuts we're hurting as far as
extra personnel are concerned...
--
Jeffrey W. Roach
MCSE, MCSA, CNA, Network+, A+
"Alan Davis" <T> wrote in message
news:5t315v8kr7q41pgokiv3ja30t
c17ag438j@4ax.com...
> >Oh yeah we have a new app running on
> >MYSQL...
>
> Insane.... It's been a while since I looked at mysql. Does it now
> support transactions and does it's locking strategies go past applying
> a single 'file lock' in order stop concurrent access?
| |
| Alan Davis 2003-02-17, 11:23 am |
| X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: microsoft.public.cert.mcdba
NNTP-Posting-Host: host62-7-149-46.webport.bt.net 62.7.149.46
Path: TK2MSFTNGP08!TK2MSFTNGP10
Lines: 1
Xref: TK2MSFTNGP08 microsoft.public.cert.mcdba:4904
>I'm not sure, its a turnkey solution that our Fire Department and GIS
>Department bought for reverse 911, the company uses a dial-in to maintain
>it, which is fine because of Davis' budget cuts we're hurting as far as
>extra personnel are concerned...
Your point being....
| |
| Jacco Schalkwijk 2003-02-17, 3:24 pm |
| Yep, people are hired on their (mostly fabricated) cv's, instead of having
their actual skills tested. Where SQL is actually one of the areas where it
is easiest to weed out the imposters, just ask for something that requires
an outer join ;-)
"Alan Davis" <T> wrote in message
news:7q425vone88tii0d5k9a10l5e
0eb7khg9p@4ax.com...
> >incompetent network admins actually, rather than dba's. You don't really
> >need to expose port 1434 for any reason at all
>
> Exactly, who said anything about dba's?
>
> >Just subscribe to microsoft.public.sqlserver.programming and see how
often
> >people come up with cursors/dynamic sql/non-normalised designs etc. It's
> >scary.....
>
> Not quite - it is VERY scary!
| |
| Jeffrey W. Roach 2003-02-17, 4:23 pm |
| I was awnsering the question about MySQL, I was basically saying that it is
the Database we don't have to mess with, the Vendor does all the work it was
part of the price... I'm sorry if it confused the issue...
--
Jeffrey W. Roach
MCSE, MCSA, CNA, Network+, A+
"Alan Davis" <T> wrote in message
news:a8625vgqndhiuvg8gl8ipe8td
un0ne8prs@4ax.com...
> >I'm not sure, its a turnkey solution that our Fire Department and GIS
> >Department bought for reverse 911, the company uses a dial-in to maintain
> >it, which is fine because of Davis' budget cuts we're hurting as far as
> >extra personnel are concerned...
>
> Your point being....
| |
| Alan Davis 2003-02-17, 4:23 pm |
| >I was awnsering the question about MySQL, I was basically saying that it is
>the Database we don't have to mess with, the Vendor does all the work it was
>part of the price... I'm sorry if it confused the issue...
I did not understand the "Davis' budget cuts" bit....
| |
| Christopher Hance 2003-02-17, 6:23 pm |
| And watch as some "incredibly qualified person" uses a server-side cursor,
when you specified numerous concurrent users as a requirement ;-)
"Sorry, we can't hire you. We've only got an 8-way Xeon system."
-Chris
"Jacco Schalkwijk" <NOSPAMjaccos@eurostop.co.uk> wrote in message
news:#$CJAOs1CHA.2204@TK2MSFTNGP09...
> Yep, people are hired on their (mostly fabricated) cv's, instead of having
> their actual skills tested. Where SQL is actually one of the areas where
it
> is easiest to weed out the imposters, just ask for something that requires
> an outer join ;-)
| |
|
| Yeah, you would be surprised how many stored procedures written in this way
I've seen. The excuse was that they had to move the functionality from C++
to SQL so they followed the exact C++ implementation!!!
Lucky me! I got to rewrite those stored procedures and guess what? Some of
them are now 10-15 times faster than the previous C++ like implementation.
Danut
"Christopher Hance" <chris@acceleration.net> wrote in message
news:uvkKx0t1CHA.2400@TK2MSFTNGP11.phx.gbl...
> And watch as some "incredibly qualified person" uses a server-side cursor,
> when you specified numerous concurrent users as a requirement ;-)
>
> "Sorry, we can't hire you. We've only got an 8-way Xeon system."
>
> -Chris
>
> "Jacco Schalkwijk" <NOSPAMjaccos@eurostop.co.uk> wrote in message
> news:#$CJAOs1CHA.2204@TK2MSFTNGP09...
> > Yep, people are hired on their (mostly fabricated) cv's, instead of
having
> > their actual skills tested. Where SQL is actually one of the areas where
> it
> > is easiest to weed out the imposters, just ask for something that
requires
> > an outer join ;-)
>
>
| |
| Jeffrey W. Roach 2003-02-17, 7:23 pm |
| Oh, He's the Governor of the State of California, his budget proposal will
cost the city I work for $15 million dollars out of our City's Budget. He
already has taken $700,000 and CALPERS (state retirement) is requiring the
city pay an additional 5-7 million due to losses in the Stock Market. So our
city leaders trying to proactive have laid off all Temp Employees and
instituted a hiring freeze. Our IT department loss some temps and we have
multiple positions we can't fill, yet our work load has only increased. So
not having to support the MySQL DB was a nice surprise.
--
Jeffrey W. Roach
MCSE, MCSA, CNA, Network+, A+
"Alan Davis" <T> wrote in message
news:srm25vodabavrh31cqn1ovsud
gq1bcieii@4ax.com...
> >I was awnsering the question about MySQL, I was basically saying that it
is
> >the Database we don't have to mess with, the Vendor does all the work it
was
> >part of the price... I'm sorry if it confused the issue...
>
> I did not understand the "Davis' budget cuts" bit....
| |
| Alan Davis 2003-02-18, 1:23 am |
| >Oh, He's the Governor of the State of California, his budget proposal will
>cost the city I work for $15 million dollars out of our City's Budget. He
>already has taken $700,000 and CALPERS (state retirement) is requiring the
>city pay an additional 5-7 million due to losses in the Stock Market. So our
>city leaders trying to proactive have laid off all Temp Employees and
>instituted a hiring freeze. Our IT department loss some temps and we have
>multiple positions we can't fill, yet our work load has only increased. So
>not having to support the MySQL DB was a nice surprise.
Oh I see...
| |
| Alan Davis 2003-02-18, 2:23 am |
| >Yeah, you would be surprised how many stored procedures written in this way
>I've seen. The excuse was that they had to move the functionality from C++
>to SQL so they followed the exact C++ implementation!!!
This shows a typical problem which can occur when highly detailed
designs (often in a sort of pdl) are used. These designs often are
represented in linear a fashion, which means these be followed in a
likewise manner.
simple example
for each customer cust
set cust_total = 0
for each order for cust
add orderTotal to cust_total
next order for cust
output cust.name and cust_total
next cust
| |
| Jacco Schalkwijk 2003-02-18, 5:23 am |
| Which is caused because most C++, VB etc programmers have no clue that SQL
is a totally different kind of beast than what they are working with.
Someone will have written a better discussion about this than I can (please
point me if you find it) but from my point of view most people just don't
understand that SQL is based on a totally different kind of math than
OO/procedural languages. Even someone like Joel Spolsky
(www.joelonsoftware.com) who I hold in high regard in matters of development
management, programming concepts etc, doesn't seem to understand:
"The SQL language is meant to abstract away the procedural steps that are
needed to query a database, instead allowing you to define merely what you
want and let the database figure out the procedural steps to query it. But
in some cases, certain SQL queries are thousands of times slower than other
logically equivalent queries. A famous example of this is that some SQL
servers are dramatically faster if you specify "where a=b and b=c and a=c"
than if you only specify "where a=b and b=c" even though the result set is
the same. You're not supposed to have to care about the procedure, only the
specification. But sometimes the abstraction leaks and causes horrible
performance and you have to break out the query plan analyzer and study what
it did wrong, and figure out how to make your query run faster."
(http://www.joelonsoftware.com/artic...stractions.html)
SQL isn't meant to abstract away the procedural steps to query the database.
SQL IMHO is a language that is designed to build mathematical constructs
based on set theory. The actual way the database is queried is defined by
the database engine, but that is implementation specific. But as I pointed
out this is lost on almost all application developers, who have a different
mental picture of the way a database works.
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Alan Davis" <T> wrote in message
news:dbn35vgjr4045jav28hd9lb2o
lua1ncquk@4ax.com...
> >Yeah, you would be surprised how many stored procedures written in this
way
> >I've seen. The excuse was that they had to move the functionality from
C++
> >to SQL so they followed the exact C++ implementation!!!
>
> This shows a typical problem which can occur when highly detailed
> designs (often in a sort of pdl) are used. These designs often are
> represented in linear a fashion, which means these be followed in a
> likewise manner.
>
> simple example
>
> for each customer cust
> set cust_total = 0
> for each order for cust
> add orderTotal to cust_total
> next order for cust
> output cust.name and cust_total
> next cust
| |
| Alan Davis 2003-02-18, 5:23 am |
| >Which is caused because most C++, VB etc programmers have no clue that SQL
Not true. It's caused ny ignorance and stupidity applied within the
software development process.
>SQL isn't meant to abstract away the procedural steps to query the database.
Well it does in way. Working with SQL (or relational algebra), you do
not care how the processing is performed.
>SQL IMHO is a language that is designed to build mathematical constructs
>based on set theory.
Exactly. Which leads to another point, why are formal methods seldom
used in the software development process?
On Tue, 18 Feb 2003 11:09:04 -0000, "Jacco Schalkwijk"
<NOSPAMjaccos@eurostop.co.uk> wrote:
>Which is caused because most C++, VB etc programmers have no clue that SQL
>is a totally different kind of beast than what they are working with.
>Someone will have written a better discussion about this than I can (please
>point me if you find it) but from my point of view most people just don't
>understand that SQL is based on a totally different kind of math than
>OO/procedural languages. Even someone like Joel Spolsky
>(www.joelonsoftware.com) who I hold in high regard in matters of development
>management, programming concepts etc, doesn't seem to understand:
>
>"The SQL language is meant to abstract away the procedural steps that are
>needed to query a database, instead allowing you to define merely what you
>want and let the database figure out the procedural steps to query it. But
>in some cases, certain SQL queries are thousands of times slower than other
>logically equivalent queries. A famous example of this is that some SQL
>servers are dramatically faster if you specify "where a=b and b=c and a=c"
>than if you only specify "where a=b and b=c" even though the result set is
>the same. You're not supposed to have to care about the procedure, only the
>specification. But sometimes the abstraction leaks and causes horrible
>performance and you have to break out the query plan analyzer and study what
>it did wrong, and figure out how to make your query run faster."
>(http://www.joelonsoftware.com/artic...stractions.html)
>
>SQL isn't meant to abstract away the procedural steps to query the database.
>SQL IMHO is a language that is designed to build mathematical constructs
>based on set theory. The actual way the database is queried is defined by
>the database engine, but that is implementation specific. But as I pointed
>out this is lost on almost all application developers, who have a different
>mental picture of the way a database works.
| |
| Danut 2003-02-19, 11:23 pm |
| Even worse
CREATE TABLE #tmp1 (Field1 INT, ... )
INSERT INTO #tmp1
SELECT Field23, blah ... FROM Table2
IF @StartDate = @EndDate AND @EndDate < GetDate()
BEGIN
SELECT Field67, blah ... FROM Table2
INTO #tmp1
END
CREATE TABLE #tmp2 (Field2 INT, ...)
INSERT INTO #tmp2 (Field2, blah, ... )
SELECT SUM(Field1), blah, ... FROM #tmp1
GROUG BY blah
and so on. About 9 temporary tables in one stored procedure.
And some people wonder why a report takes over 50 minutes when there are
only 200,000 records in 3-4 tables.
"Alan Davis" <T> wrote in message
news:dbn35vgjr4045jav28hd9lb2o
lua1ncquk@4ax.com...
> >Yeah, you would be surprised how many stored procedures written in this
way
> >I've seen. The excuse was that they had to move the functionality from
C++
> >to SQL so they followed the exact C++ implementation!!!
>
> This shows a typical problem which can occur when highly detailed
> designs (often in a sort of pdl) are used. These designs often are
> represented in linear a fashion, which means these be followed in a
> likewise manner.
>
> simple example
>
> for each customer cust
> set cust_total = 0
> for each order for cust
> add orderTotal to cust_total
> next order for cust
> output cust.name and cust_total
> next cust
| |
| Danut 2003-02-19, 11:23 pm |
| I agree that "SQL is a language that is designed to build mathematical
constructs based on set theory" but the guy is right that on SQL Server 2000
adding "and a=c" improves the performance a lot in some cases even if it
does not change the logic at all.
"Jacco Schalkwijk" <NOSPAMjaccos@eurostop.co.uk> wrote in message
news:#Ve3d2z1CHA.1900@TK2MSFTNGP10...
> Which is caused because most C++, VB etc programmers have no clue that SQL
> is a totally different kind of beast than what they are working with.
> Someone will have written a better discussion about this than I can
(please
> point me if you find it) but from my point of view most people just don't
> understand that SQL is based on a totally different kind of math than
> OO/procedural languages. Even someone like Joel Spolsky
> (www.joelonsoftware.com) who I hold in high regard in matters of
development
> management, programming concepts etc, doesn't seem to understand:
>
> "The SQL language is meant to abstract away the procedural steps that are
> needed to query a database, instead allowing you to define merely what you
> want and let the database figure out the procedural steps to query it. But
> in some cases, certain SQL queries are thousands of times slower than
other
> logically equivalent queries. A famous example of this is that some SQL
> servers are dramatically faster if you specify "where a=b and b=c and a=c"
> than if you only specify "where a=b and b=c" even though the result set is
> the same. You're not supposed to have to care about the procedure, only
the
> specification. But sometimes the abstraction leaks and causes horrible
> performance and you have to break out the query plan analyzer and study
what
> it did wrong, and figure out how to make your query run faster."
> (http://www.joelonsoftware.com/artic...stractions.html)
>
> SQL isn't meant to abstract away the procedural steps to query the
database.
> SQL IMHO is a language that is designed to build mathematical constructs
> based on set theory. The actual way the database is queried is defined by
> the database engine, but that is implementation specific. But as I pointed
> out this is lost on almost all application developers, who have a
different
> mental picture of the way a database works.
>
> --
> Jacco Schalkwijk MCDBA, MCSD, MCSE
> Database Administrator
> Eurostop Ltd.
>
>
> "Alan Davis" <T> wrote in message
> news:dbn35vgjr4045jav28hd9lb2o
lua1ncquk@4ax.com...
> > >Yeah, you would be surprised how many stored procedures written in this
> way
> > >I've seen. The excuse was that they had to move the functionality from
> C++
> > >to SQL so they followed the exact C++ implementation!!!
> >
> > This shows a typical problem which can occur when highly detailed
> > designs (often in a sort of pdl) are used. These designs often are
> > represented in linear a fashion, which means these be followed in a
> > likewise manner.
> >
> > simple example
> >
> > for each customer cust
> > set cust_total = 0
> > for each order for cust
> > add orderTotal to cust_total
> > next order for cust
> > output cust.name and cust_total
> > next cust
>
>
| |
| Alan Davis 2003-02-20, 1:23 am |
| lol!
On Wed, 19 Feb 2003 22:48:10 -0600, "Danut" <danutzp1@hotmail.com>
wrote:
>Even worse
>
>CREATE TABLE #tmp1 (Field1 INT, ... )
>
>INSERT INTO #tmp1
> SELECT Field23, blah ... FROM Table2
>
>IF @StartDate = @EndDate AND @EndDate < GetDate()
>BEGIN
> SELECT Field67, blah ... FROM Table2
> INTO #tmp1
>END
>
>CREATE TABLE #tmp2 (Field2 INT, ...)
>
>INSERT INTO #tmp2 (Field2, blah, ... )
> SELECT SUM(Field1), blah, ... FROM #tmp1
> GROUG BY blah
>
>and so on. About 9 temporary tables in one stored procedure.
>
>And some people wonder why a report takes over 50 minutes when there are
>only 200,000 records in 3-4 tables.
>
>
>"Alan Davis" <T> wrote in message
> news:dbn35vgjr4045jav28hd9lb2o
lua1ncquk@4ax.com...
>> >Yeah, you would be surprised how many stored procedures written in this
> way
>> >I've seen. The excuse was that they had to move the functionality from
> C++
>> >to SQL so they followed the exact C++ implementation!!!
>>
>> This shows a typical problem which can occur when highly detailed
>> designs (often in a sort of pdl) are used. These designs often are
>> represented in linear a fashion, which means these be followed in a
>> likewise manner.
>>
>> simple example
>>
>> for each customer cust
>> set cust_total = 0
>> for each order for cust
>> add orderTotal to cust_total
>> next order for cust
>> output cust.name and cust_total
>> next cust
>
| |
| Jacco Schalkwijk 2003-02-20, 4:24 am |
| Most of the reporting stuff where I work has been written like that :'(
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Danut" <danutzp1@hotmail.com> wrote in message
news:#tQWZvJ2CHA.2296@TK2MSFTNGP10.phx.gbl...
> Even worse
>
> CREATE TABLE #tmp1 (Field1 INT, ... )
>
> INSERT INTO #tmp1
> SELECT Field23, blah ... FROM Table2
>
> IF @StartDate = @EndDate AND @EndDate < GetDate()
> BEGIN
> SELECT Field67, blah ... FROM Table2
> INTO #tmp1
> END
>
> CREATE TABLE #tmp2 (Field2 INT, ...)
>
> INSERT INTO #tmp2 (Field2, blah, ... )
> SELECT SUM(Field1), blah, ... FROM #tmp1
> GROUG BY blah
>
> and so on. About 9 temporary tables in one stored procedure.
>
> And some people wonder why a report takes over 50 minutes when there are
> only 200,000 records in 3-4 tables.
>
>
> "Alan Davis" <T> wrote in message
> news:dbn35vgjr4045jav28hd9lb2o
lua1ncquk@4ax.com...
> > >Yeah, you would be surprised how many stored procedures written in this
> way
> > >I've seen. The excuse was that they had to move the functionality from
> C++
> > >to SQL so they followed the exact C++ implementation!!!
> >
> > This shows a typical problem which can occur when highly detailed
> > designs (often in a sort of pdl) are used. These designs often are
> > represented in linear a fashion, which means these be followed in a
> > likewise manner.
> >
> > simple example
> >
> > for each customer cust
> > set cust_total = 0
> > for each order for cust
> > add orderTotal to cust_total
> > next order for cust
> > output cust.name and cust_total
> > next cust
>
>
| |
| somebody 2003-02-22, 12:23 am |
| Maybe Microsoft should make some part of the exam subjective, like what Sun did with its Java
certifications (essay questions/assignments). But of course that would mean they would need people
to mark the papers, and the results can be biased, but hey, its just like any other exam. I don't
think brain dumps would be able to cover the subjective parts of the exam. Would it ? (",)
On Sun, 16 Feb 2003 18:42:10 -0500, "Christopher Hance" <chris@acceleration.net> wrote:
>Well-read, even, with the reference to "paper tiger[s]," commonly attributed
>to Chairman Mao of Communist China. And it meets the minimum grammatical
>error requirement. Corrected: "When the database goes to hell and I can't
>fix it, I'll say, 'But I am an MCDBA.'" I'll even concede that point for
>those who "learn" solely from brain dumps. I'm a bit conceited that I passed
>087/228/229 from experience, without "learning for the test," but I try to
>understand the existential dilemma for those who don't have experience and
>are trying to get it.
>
>Now as for the last part:
>real: well, there seems to be some demand for MSSQL skills in the "real"
>world
>relational: yep, it's got multiple tables, foreign keys, all kinds of joins
>database: hmm, stores data in tables. Typical structure of a database.
>management system: well, one can add/delete/update schema and data, manage
>indexes, filegroups, et al. Seems to fit here too.
>
>MSSQL seems to meet the qualifications for a "real rdbms." Granted it's a
>little more intuitive than Oracle, with which a qualified DBA should
>probably have some familiarity unless the job description specifically
>states that there will never be any cross-vendor database interaction.
>Still, there seems to be fluctuation as to which actually runs faster and/or
>better on a given piece of hardware. And then there's DB2, the hardware for
>which exceeds most small/medium-business IT budgets. And mysql, which was
>still working on the enforced relationships part last I heard. So define
>"real" for me.
>
>I'm going to stop my intellectual analysis before the "real os" part. Odd
>that someone with this attitude signs up to msnews.microsoft.com or bothers
>visiting the online forums on the microsoft.com site.
>
>Hmm, so does arguing semantics without resorting to insults qualify as
>"feeding the troll?" I knew I would regret it when I left my flamethrower in
>the car.
|
|
|
|
|