June 1, 2013 at 6:24 am
Jack Corbett (5/31/2013)
Have I mentioned these 2 things lately:1. I can't stand ORM tools and the queries they create
2. I can't stand when developers create databases without a data professional involved.
Thanks,
JACK! I've missed you! How are things going (besides frustrating) in your neck of the woods.
June 1, 2013 at 7:01 am
Jack Corbett (5/31/2013)
Have I mentioned these 2 things lately:1. I can't stand ORM tools and the queries they create
2. I can't stand when developers create databases without a data professional involved.
Thanks,
The great thing about ORM tools is that once you've seen some of the things they do you begin to think that half-educated developers writing their own half-baked SQL is better than letting one of those tools do it. After all, developers can be trained but I've never heard of anyone training an ORM to do things anywhere near right.
Tom
June 3, 2013 at 1:56 am
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.
:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
Far away is close at hand in the images of elsewhere.
Anon.
June 3, 2013 at 6:17 am
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
June 3, 2013 at 6:29 am
Greg Edwards-268690 (6/3/2013)
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
The worst is when they include 20+ "User Defined fields" called User1, User2, etc...
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
June 3, 2013 at 6:46 am
GilaMonster (6/1/2013)
Jack Corbett (5/31/2013)
So once we get a good amount of data in that table I'm pretty sure any index that doesn't have columnA as the leading column will require a scanNo.
An unselective leading column does not mean a scan (and I've often created indexes with a bit as the leading column). It's not going to be the most efficient seek, but unless there's no sargable predicate on the leading column, you will get a seek.
If the entire of the index is unselective and is not covering, then SQL will likely switch to a scan of the clustered index (unless there are other covering indexes)
Okay, that is true, but at least in this case, they aren't always including the bit column in the predicate, so if the index is created with the bit column leading, then another index with a more selective column as the lead column is required as well.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 3, 2013 at 6:47 am
Brandie Tarvin (6/1/2013)
Jack Corbett (5/31/2013)
Have I mentioned these 2 things lately:1. I can't stand ORM tools and the queries they create
2. I can't stand when developers create databases without a data professional involved.
Thanks,
JACK! I've missed you! How are things going (besides frustrating) in your neck of the woods.
Shouldn't complain, even though I do. Life is good other than the minor irritations of the job, which everyone has.
Planning on coming down for the Orlando SQLSaturday in September at least at this point.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 3, 2013 at 7:03 am
Stefan Krzywicki (6/3/2013)
Greg Edwards-268690 (6/3/2013)
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
The worst is when they include 20+ "User Defined fields" called User1, User2, etc...
Maybe that's what they are saving - not having to define a name that means anything.
That could limit (or draw questions) if the field represents mulitple things.
And everyone knows that nvarchar(max) is very flexible.
Data types? Just an unecessary constraint!
June 3, 2013 at 7:07 am
Greg Edwards-268690 (6/3/2013)
Stefan Krzywicki (6/3/2013)
Greg Edwards-268690 (6/3/2013)
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
The worst is when they include 20+ "User Defined fields" called User1, User2, etc...
Maybe that's what they are saving - not having to define a name that means anything.
That could limit (or draw questions) if the field represents mulitple things.
And everyone knows that nvarchar(max) is very flexible.
Data types? Just an unecessary constraint!
To be fair, I don't have a problem with a properly typed column that stores several different types of data with a lookup key determining what that data is, but the properly typed column is the important qualifier here. Before SPARSE columns, that was a good way to handle rarely updated columns. It can still make sense if done properly.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
June 3, 2013 at 8:23 am
Stefan Krzywicki (6/3/2013)
Greg Edwards-268690 (6/3/2013)
Stefan Krzywicki (6/3/2013)
Greg Edwards-268690 (6/3/2013)
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
The worst is when they include 20+ "User Defined fields" called User1, User2, etc...
Maybe that's what they are saving - not having to define a name that means anything.
That could limit (or draw questions) if the field represents mulitple things.
And everyone knows that nvarchar(max) is very flexible.
Data types? Just an unecessary constraint!
To be fair, I don't have a problem with a properly typed column that stores several different types of data with a lookup key determining what that data is, but the properly typed column is the important qualifier here. Before SPARSE columns, that was a good way to handle rarely updated columns. It can still make sense if done properly.
Properly typed, rarely updated help. Although when we did that, we found over time, we would usually end up normalizing anyways.
Having to insert logic somewhere to get the correct data out can be an issue if users have access and don't understand this. And sometimes leads to multiple places to maintain as changes occur.
Depends on your evironment to some extent.
June 3, 2013 at 8:32 am
Greg Edwards-268690 (6/3/2013)
Stefan Krzywicki (6/3/2013)
Greg Edwards-268690 (6/3/2013)
David Burrows (6/3/2013)
Jack Corbett (5/31/2013)
2. I can't stand when developers create databases without a data professional involved.:ermm:
I'm a developer, I create databases without a data professional as I do not have one to consult (nor a DBA) :rolleyes:
I suppose it makes me the DBA :pinch:
When you have to work with what you create, you learn from your mistakes.
Which can be the best way to learn.
No problem with those that can switch hats during the day.
Sometimes since they know the whole picture, very solid solutions come into use.
What I hate is the developers that try to make 1 column represent multiple things, then code logic around it.
If column A has a Work Center, then column B is production quantity for the work center.
If column A is a Department, then column B is total qty for the day for the department.
If column is NULL, then column B is something completely different.
I don't know what they think they are saving.
The worst is when they include 20+ "User Defined fields" called User1, User2, etc...
Maybe that's what they are saving - not having to define a name that means anything.
That could limit (or draw questions) if the field represents mulitple things.
And everyone knows that nvarchar(max) is very flexible.
Data types? Just an unecessary constraint!
I've run into this several times before. It allows for (just saying it outloud for those that might not know) "user definable 'tables'" and it all boils down to "EAV"s (considered to be scourge of the Earth to many). The problem is that most people make the mistake of using (for example) NVARCHAR(MAX) for such things which, of course, blows away any type of metadata about the datatype. When people do these things (EAVs), they should take the time to learn a bit more about how to use the SQL_Variant datatype. They're not a datatype panacea for EAVs but they come a whole lot closer than converting everything to NVARCHAR.
--Jeff Moden
June 3, 2013 at 9:43 am
Speaking of SQL_Variant, does anyone here actually use it?
I've never found a reason to use it or a need that made sense, so I'd love to hear real world cases of why and where others might use it.
June 3, 2013 at 9:45 am
I just use it for all my columns. That way I never get any pesky datatype errors.
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
June 3, 2013 at 9:47 am
Brandie Tarvin (6/3/2013)
Speaking of SQL_Variant, does anyone here actually use it?I've never found a reason to use it or a need that made sense, so I'd love to hear real world cases of why and where others might use it.
I have used it at a previous employer where I needed to profile a database and capture min/max/avg(if exists), unique values and count (the count was not stored in a sql_variant).
This was a SQL Server 2000 database so I didn't have the tools available now with SSIS.
June 3, 2013 at 9:52 am
The Dixie Flatline (6/3/2013)
I just use it for all my columns. That way I never get any pesky datatype errors.
Works great for all types except the MAX types (varchar(max), etc.).
Viewing 15 posts - 40,036 through 40,050 (of 66,000 total)
You must be logged in to reply to this topic. Login to reply