|
Jeremy Falcon wrote: a variable / large amount of data
That doesn't sound like a translation table.
Jeremy Falcon wrote: quick short constant that's only particular to one table
Yeah, like that. Small amounts of static data; as with status codes, transaction types, etc.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: That doesn't sound like a translation table.
Using your terminology. I usually call them a look-up table, but when in Rome.
PIEBALDconsult wrote: Yeah, like that. Small amounts of static data; as with status codes, transaction types, etc.
Which is my point, SQL Server needs a type for that. A good example would be like a three state Boolean. Sure you can use 0, 1, and 2 but something like F, T, and * is much more readable.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: look-up table
Same thing -- look up the translation for some code. They were called translation tables when I was using Oracle in the 90s.
Jeremy Falcon wrote: SQL Server needs a type for that
I see no need to have a special type and all the added functionality it entails; it's just another table.
Jeremy Falcon wrote: F, T, and * is much more readable
Well, that's what this whole thread is discussing, but it seems you have a camp all your own  , right in between the others -- insert a character but actually store a number.
I work with a lot of databases, including MySQL, and I prefer to stay within the common areas as much as possible, and I need a pretty good reason to use something that only one database supports.
So sure, just as SQL Server recently added sequences (which Oracle has had for longer than I can recall), it seems like a reasonable feature to add -- to increase that common area.
But this particular feature seems like it could hurt performance with very little benefit -- I don't see how it can perform better than the current way that translation/look-up tables are used, and may be (slightly) worse.
As with SELECT *, I think it's a boon to interactive users who can benefit from a way to reduce command length and complexity (primarily by eliminating JOINs), but not something that an application benefits from. You've probably heard the arguments against SELECT * in code.
Performance is also not as big a concern with interactive users writing ad hoc queries as it is with 24/7 enterprise applications.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Well, that's what this whole thread is discussing, but it seems you have a camp all your own
Because this is mainly MS devs that never used an ENUM in a DB before. Of course I'm going to be "in a camp all my own" here.
PIEBALDconsult wrote: But this particular feature seems like it could hurt performance with very little benefit
You must be bored and just want to argue. Seriously, do I have to explain why a join on a look-up table is slower?
You're just arguing man. I use your term, you argue with that on semantics. I explain my term, then you explain to me why you use yours, which tells me we were on the same page by using your term in the first place and you know what I meant. Seriously, do you really like to argue that much?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Of course I'm going to be "in a camp all my own"
I usually am too.
Jeremy Falcon wrote: do I have to explain why a join on a look-up table is slower?
Perhaps you could explain how it would implement the automatic translation/look-up without performing a JOIN behind the scenes?
Jeremy Falcon wrote: you know what I meant
You appeared to not know what I meant.
Jeremy Falcon wrote: do you really like to argue
No, but I want to be sure talking about the same thing. I think we are now.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Perhaps you could explain how it would implement the automatic translation/look-up without performing a JOIN behind the scenes?
There is no look-up with an ENUM data type. It's just a data type. Instead of using a number with no inherit value, with no referential data checking for a rogue number, etc. you can use strings. Not only is there no look-up, which is fast, this has so many advantages with automatic data checking / integrity (even in the case of a tri-state Boolean) it's unreal.
PIEBALDconsult wrote: You appeared to not know what I meant.
I did. And like I said, ENUM types fall short on variable length rows of values / types / whatever you want call them. And if the look-up needs to be re-used they fall short. But for a one-time small item, such as tri-state Boolean they're awesome.
PIEBALDconsult wrote: I think we are now.
I've always been talking about this yo.
Jeremy Falcon
|
|
|
|
|
Numbers, definitely numbers. And not just any numbers but enumerated numbers 
And preferrably even listed in a look up table and enforced with constraints.
|
|
|
|
|
I work in an open plan office, I'm 3 down a row of desks from the window.
Is it fair that I blame the bloke who sits closest to the window for the weather outside it?
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
What are you going to do if you get cold at the office?
|
|
|
|
|
I can't see why not, I've blamed someone I work with, that it is his fault it began raining at lunchtime because he went swimming 
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
yes, if he doesn't like it he can swop with you
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Using MSVC 12/VS2013.
Why? Why not?
So far I have built Python 3.4.1 successfully, and I am currently working on building Python 2.7.8.
I will upload these builds and post a link here if people want me to.
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
Brisingr Aerowing wrote: So far I have built Python 3.4.1 successfully, and I am currently working on building Python 2.7.8.
So you regress. 
Once you lose your pride the rest is easy.
I would agree with you but then we both would be wrong.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Some things only work on Python 2.x, like Mercurial.
I have both built now, and they both work perfectly.
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
|
I am building CPython.
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
What to do if you are sleepy at office?
|
|
|
|
|
Post a new message at the Lounge.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
|
At office 3 coming soon eh?
|
|
|
|
|
At office 3 coming soon Laugh | Laugh | Laugh | Laugh | Laugh | Laugh | Laugh | eh?
|
|
|
|
|
Stop reading posts like this!
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
a) close door - take a power nap.
or
b) go up to cabin - take a power nap.
or
c) go outside walk round the plant and get some fresh sea air.
|
|
|
|
|
Paint blue circles on your eyelids and try not to snore...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Mine are green 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
