February 9, 2015 at 11:54 am
patrickmcginnis59 10839 (2/9/2015)
Stack exchange is a personal go to for information on a span of subject matter that vastly exceeds anything sqlservercentral will EVER aspire to in the slightest
Having posted there and seen many of the posts there, I have to say that I strongly disagree with that statement. I also disagree because discussion is usually suppressed and many questions/answers are deemed inappropriate just because they usually don't approve of anything other than ask a question or post an answer... even if it's horribly wrong.
I do, however, agree with you last couple of comments...
And I can say that even as I clearly enjoy reading and posting here as well.
You get good posts and bad posts everywhere. 2 cents.
As you say, just my 2 cents. 😉
--Jeff Moden
February 9, 2015 at 12:27 pm
It was not my intention to rubbish stack exchange, I use it regularly for non SQL related activities. My point was that a lot of the people who post at SX are generalists (or at least polyglots) and that in general the level of knowlege is not as extensive in SQL as it is here. Plus as Jeff says, the forums are very dry because anything which is not asking or answering a question gets shut down very quickly. In addition, questions are closed off after a very short period of time whereas questions are always open at SQLSC.
Each to their own, but for specific technologies I tend to use technology specific board
MrExcel for Excel
BOB (Business Objects Board )
CodeIgniter forum for CI issues
SX is great for generalist questions, and for open-source issues, but you have to take the answers in the context of they may not have been posted by an 'expert' in their field.
February 9, 2015 at 12:44 pm
CELKO (2/8/2015)
I want him to leave with more than a kludge he does not understand, so that when he does have "experience, authority or gravitas to engage for a database change", he will remember this ("That pain in *** Celko said something about this to me once .. I remember! :Wow: "
If this is really the goal I fear your approach may be counter-productive.
I would be honestly surprised if people with questions of this level would retain any lesson at all from such a rant. I would be far less surprised if they dismissed it as a TL;DR the moment they realized it did not contain the solution they sought nor a way to get it, and thus did not even get through it all.
February 9, 2015 at 1:26 pm
aaron.reese (2/9/2015)
@patrick,It was not my intention to rubbish stack exchange, I use it regularly for non SQL related activities. My point was that a lot of the people who post at SX are generalists (or at least polyglots) and that in general the level of knowlege is not as extensive in SQL as it is here. Plus as Jeff says, the forums are very dry because anything which is not asking or answering a question gets shut down very quickly. In addition, questions are closed off after a very short period of time whereas questions are always open at SQLSC.
I can grant you that! I'm probably more of a generalist, and given all the different technologies I get into, sqlservercentral just can't match what SE offers. Even in competition with tech specific stuff, SE competes well and I really like the format. I obviously haven't seen a material amount of incorrect stuff, but I'm sure there have been some degenerate cases of incorrect or bad threads over there. Simply based on scale and variety of moderators, I think thats to be expected, but I've always been a big fan of moderated forums and I really like that crowdsourcing.
I think its a very valid thing to point out drawbacks to any given site, and I'm not going to object to that. I do think SE could be more discussion oriented, but I acknowledge thats not the direction they've taken. Its just that the scale and coverage they do is nuts, and I really appreciate that, and just based on this, I try to demonstrate as an sqlservercentral user, that not everyone dislikes that place. (I also think counter opinions on subjective matters helps even the community here out a bit.)
Also I'm really into open source and programming languages and that weighs into my preferences obviously.
February 10, 2015 at 10:15 am
aaron.reese (2/8/2015)
Well said Jeff,@joe, it would be lovely to live in your SQL bubble where all RDMS is built and managed by people with 20 years experience, a masters degree in computer engineering and no commercial pressures. Unfortunately most of the folks who are posting that sort of question here are noobs, who have inherited an inherantly bad database design built by untrained application developers who are completely reliant on the current data types and structures where the OP has been tasked with doing something is is fundmentally difficult because of the bad design. usually the OP does not have the experience, authority or gravitas to engage for a database change, and even if they did, it does not help them to produce that report by the end of the week.
Don't come stomping in here with you size 12s, making people feel small just to show your superiority in the database design space. I am going to assume that you mean well, but be more understanding of people on the lower rungs of the SQL career ladder please. Otherwise these good meaning folk will simply go to StackExchange and continue to receive bad advice from well-meaning but less knowlegeable forum members for whom the database is simply a tool to hold persistent data and for whom performance and managagement are secondary considerations (if at all)
Is this a professional forum, or one for hobbyists? I realize there are plenty of developers who get things dropped in their laps that are outside their expertise, but many of these questions betray a lack of any attempt to approach the problem as an engineer. When you get handed crap, it is still your responsibility to analyze the problem, and when you determine that you need help, to articulate the problem in a meaningful way.
Don Simpson
February 10, 2015 at 10:41 am
No, but it is common design error. Unfortunately we have no DDL, so we have to start guessing. I also see you put one field [sic] or keyword per line [punch card]; this is a very strong code smell that tells me you are still in a file system mindset. Is this certain? No, but after 30+ years of fixing bad SQL, it is how I will bet.
I like to post a field per line for my queries. Am I in a file system mindset? Sure, why not, filesystems are a strong abstraction over platters, cylinders and sectors. So whats the downside to a field per line? Oftentimes I get involved in mapping between systems, and having a field per line makes for a natural guide to matching fields from one table or query to another. When having to decipher other folks code, I'll take their many fields to a line formatting, throw them in a text editor and break the fields and expressions down to individual lines to make sense of it. Additionally, since they're easily translated from one form to another whats the big deal?
And why are fields on an individual line even linked to file systems to begin with? I'm not making the connection, but I'm always happy to be lectured to by a legend, I'm not too proud to change my ways, but I'm going to need an explanation to even begin to consider this given my experiences.
Remember, I'm stuck in the real world too 😉
February 10, 2015 at 11:36 am
DonlSimpson (2/10/2015)
Is this a professional forum, or one for hobbyists? I realize there are plenty of developers who get things dropped in their laps that are outside their expertise, but many of these questions betray a lack of any attempt to approach the problem as an engineer. When you get handed crap, it is still your responsibility to analyze the problem, and when you determine that you need help, to articulate the problem in a meaningful way.
There are a wide variety of people who end up needing to do some T-SQL, and they have a wide variety of expertise and background, not to mention native language. Often, in addition to their specific problem, how to articulate it is one of the things they do not know.
It seems to me far more productive to nudge them along with help as well as advice/examples on how to better format their question that to simply insist they do their 'responsibility'. I've seen lots of people ask first questions on here that were vague with no example (or a terrible one with bad formatting), and by the time they post their second question one of the things they've learned is what information those helping them need to know, and the question is far better. But if they are just berated for their lack of netiquette, are they more likely to put the work in to try and get things in the format those people are requesting, or simply keep asking their question elsewhere until someone helps them?
February 10, 2015 at 2:29 pm
CELKO (2/10/2015)
So whats the downside to a field per line?
Look up this common illusion:
Did you see the trick? Your brain forms clusters of letters and words called a bouma. They make reading faster than doing things letter-by-letter or word-by-word in a vertical column. Your “punch card” mindset actually adds 8-12% more time to maintaining code. We did a lot of research on this stuff in the 1970's when I was at AIRMICS.
Thats just not persuasive enough, at least for me anyways. If this is persuasive, then why am I compelled to break the columns into individual lines to match the insert items to their respective select expressions? In the seventies, could you paste separate parts of an insert statement into excel to line up the column names being inserted with the expressions that they're inserting from? Could you move separate editor windows wherever you wanted on a graphical display? I don't know, I'm asking, yes I can understand the PARC timeline, no I personally can't remember anything but greenscreens in the 70's.
Don't get me wrong, I'm not denying that you believe this and that you have certainly persuaded yourself of the advantages and somehow you've come up with 8-12 percent more time spent, but to be absolutely persuasive, it would be really nice to link some research so folks can see exactly the mechanics behind this. I'm game to being convinced.
Is this 1970's research still valid? Does the 1970's research hold up with today's interactive editors and programming language syntax? Maybe I SHOULD be putting lists of column names on as few lines as possible, so why do I in particular find that so painfully unworkable, you're not giving me the information to investigate this sort of thing, there actually could be something I can learn here, but its not going to happen with what you posted.
Remember, folks don't skim program text when they have to do analysis to an exacting degree, folks have to search for these illusions down to the letter or punctuation mark. I get your optical illusion, but does that illusion hold up to a material extent when you read programming text? Remember, these aren't paperback novels we're writing, its pickyoon computer syntax where we often have to chase down errant typos that could be one character long for petes sake.
Sure nobody says you have to convince anybody of anything, but then again, its not like you have a spotless record posting absolutely and universally lauded gems of wisdom here, right? Surely you have to have noted at least the occasional objection to a posting of yours.
I think sometimes you are all too happy to call someone else mistaken without putting in the effort to actually convince them why. I would hope you can understand how frustrating that gets, but with all the replies that don't seem to budge you, maybe I'm not mistaken to have some doubt here.
Maybe you've given up, and you don't expect folks to appreciate your text.
February 10, 2015 at 2:38 pm
Did you see the trick? Your brain forms clusters of letters and words called a bouma. They make reading faster than doing things letter-by-letter or word-by-word in a vertical column. Your “punch card” mindset actually adds 8-12% more time to maintaining code. We did a lot of research on this stuff in the 1970's when I was at AIRMICS.
This argument implies a person reading an entire query beginning to end and left to right like I would a sentence.
I can't speak for anyone else, but I find that I rarely do that, especially when "maintaining code".
I like being able to quickly see the different clauses in a select query. I like being able to quickly comment things out of the select list. I often don't look to the select list first, and when I do it is nice to be able to quickly look for columns coming from a particular table alias, or columns calculated from formulas.
And like many people working on databases today, I've scarcely if ever worked with data straight out of a file system or punch card.
February 26, 2015 at 1:07 pm
The first principle of ISO-11179 and all data element names is that you name a thing for what it is by its nature, not how or where it is used in one schema or table. That means “_key” cannot ever be what ISO calls an attribute property. That is mixing meta data into the data
I not sure I follow, but it seems this would eliminate the use of foreign keys so named in a table ... these can be labeled as attributeFkey or FK_attribute and are not confused with a entity key that a row in the table represents.
----------------------------------------------------
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply
