May 9, 2009 at 9:40 am
Jeff Moden (5/9/2009)
Florian Reischl (5/9/2009)
Jeff Moden (5/9/2009)
BTW - It is good to see growing acceptance of the idea that ANSI standards are kinda 'blah'. I couldn't agree more 🙂
Man, I agree with that. Now, if we could just get people over the idea of try for code portability on the backend. 😀
Do you work at my company? Never saw you guys. Do you have pseudonyms? They even try to keep base libraries portable... We are not allowed to use LINQ because it is not available in Java. :crazy:
Heh... I can't tell if you're agreeing with us or not. I won't speak for Paul but, to clarify my position... I'm definitely NOT a believer in the myth of portable code (in so far as SQL goes) or using only ANSI code. "Get people over the idea" means that I want to try to stop people from believing that they should forsake the power available in any given database engine just to try to make portable code.
I do, however, believe in encapsulation and I believe THAT makes things "more portable". Probably a bad example, but let's take the humble concatenation function as an example. As you know, SQL Server will allow for a variable to be "overlayed" in a single SELECT... Oracle will not. If the DB folks have done their job correctly, there will be one function each for SQL Server and Oracle in the library and each will use the "best" methods available in the given database engine for both performance and scalability. The front end folks should only have to worry about calling the function, not how it works.
On the other hand, trying to make such a concatenation function work in both SQL Server and Oracle using only ANSI code might be possible, but it's going to be a lot slower on one than on the other. With that in mind, some would say that the concatenation function should actually be a part of the GUI code and, depending on the circumstances, I might agree. But, what if there is no GUI? What if this is for file processing? 😉
So far as something like not using LINQ because it doesn't work with Java goes, that's a pretty important decision for the company one way or another. One might argue that the company has settled on Java as a programming standard and that it's easier to find developers that know just Java than it is to find developers who know both Java and LINQ. There must be a dozen or more major languages and hundreds of minor "tool" languages to write GUI's and other types of non-database-centric code with. To prevent the proverbial "tower of Babel", some companies pick a standard and stick with it just so they know they can find replacement developers that can come up to speed quickly. It's not always the best short term solution, but it usually works out in the long run.
Jeff, I completely agree with both of you!! I know (partly) the power of SQL Server if you don't just use the ANSI standards. It's just the intention of my company, trying to keep things portable in any direction. This reduces the available features to a minimal subset for every technique. It took a long time since we became allowed to use generics in C# (a great feature!) and we are still not allowed to use stored procedures because they are not portable to any other DBMS. I built one procedure some weeks ago because we had a huge performance problem with one of your processes. It was just a very small part of the complete process but the performance increased for 500%. Instead of saying "good job" I had about 5 hours with escalations and discussions... They (my chief) created a huge OR-mapper which tries to handle everything what is needed in SQL. All statements are created dynamically in front-end by this OR-mapper and the performance of the queries is annoying because everything needs to be portable between SQL Server, Oracle, Informix and MySQL.
They think since we are only 20 developers everybody needs to be able to do everything. A web-developer needs to be able to design databases and a process developer needs to be able to create windows applications. I think I know how to design a database, create a good performing process or maybe parts of windows applications but seriously keep me away from web-applications or rich GUI parts :hehe:.
A funny anecdote from the last weeks:
One of your developers (a really good front-end guy) had a new project for the last month. The project is alike an account management system the customer can enter new items, transfer them to other group members and get new from others (it's no bank system but it works like). Now the customer is able to create new items let's say 100,000. The database has a account-table and creates one row for each item (100,000 new rows in this case). At the moment the database is about 5GB what's not much but the performance is just a joke because about 95% of the complete database are only one table and every calculation will be done on this monster. The table looks like:
Id Count CustomerId
1234 1 1
Notice, there is no row with another ItemCount than "1"! :laugh:
So back to the subject. I think portability is (almost) never the best way. Independent if you try to keep the source code (including SQL) portable or if you try to keep your members portable. The best solutions are always reached with the specialist (for each part) who use the special features of their system.
Greets
Flo
May 9, 2009 at 9:55 am
Wow... that's a heck of a table. I am so not jealous of either that or the rigors they seem to be putting you through.
Thanks for the feedback, Flo.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2009 at 10:03 am
The effort-reward ratio has fallen below my personal threshold on the whole SELECT versus SET assignment thing. Anyone who thinks n SET statements is as quick as a single SELECT will just have to prove it for themselves :laugh:
Portability. Don't get me started. Ok, one quick example:
A point-of-sale application I came across 'abstracted' the database into objects and created SQL on the fly for each database operation using only the simplest SQL available. This was done in the 'data abstraction layer'. Good grief.
This approach meant that stored procedures were out - all SELECT, INSERT, UPDATE and DELETE statements have to be generated fresh each time.
The effort that went into this must have been substantial, and of course it did nothing for performance, and the readability of the generated SQL was on a par with Access' attempts to produce SQL from a query designed on a diagram. The world may run short of parentheses sometime soon due mostly to this one application.
And the benefits? Well, in theory a customer could choose any back-end database which supports very basic SELECT, INSERT, UPDATE and DELETE syntax.
When one buys the product in question, the company insists on supplying the database product at the same time. Can anyone guess how many options there are for database back-ends? Ten? Twenty?
One.
SQL Server. That's all they've ever offered, and all they ever will as far as I can tell. The product has been available for over ten years like this.
It makes me want to cry.
Paul
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
May 9, 2009 at 10:21 am
I completely know what you mean... They call it "marketing strategy" to be able to offer any DBMS.
I forgot the last funny part. The product went productive and on first day the whole application freezes. You know why... They forgot the validation for the "new items" text-box and a joker entered something like "84320583450" :laugh:
May 9, 2009 at 10:36 am
Florian Reischl (5/9/2009)
...a joker entered something like "84320583450" :laugh:
If only 'joker' were synonymous with 'tester' eh?
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
May 9, 2009 at 10:39 am
Nope. The customer!
Sure, the tester also found this "feature" (as first) but the TPM thought there is no time to fix it for the first version and the customer "for sure" would never do this...
May 9, 2009 at 10:43 am
Florian Reischl (5/9/2009)
...the TPM thought there is no time to fix it for the first version and the customer "for sure" would never do this...
If I had a dollar for every time...:laugh: :laugh: :laugh:
Er, TPM? The Project Manager??
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
May 9, 2009 at 10:50 am
Sorry, TPM is "Technical Project Manager" (people like me) in your company. Since the PM has many ACM work - I don't know why because we have a ACM department - the PM has usually not really an idea of the system. So it's my job to keep the technical parts (development, test, technical support and data-center) together.
Greets
Flo
May 9, 2009 at 11:29 am
Florian Reischl (5/9/2009)
Sorry,
:Whistling: I'm saying nothing.
Florian Reischl (5/9/2009)
TPM is "Technical Project Manager" (people like me) in your company.
We don't have those. We have small teams - an analyst, someone from site design, a developer, a tester, and a database person usually. Pretty much everyone is equal. We don't even have job titles!
Florian Reischl (5/9/2009)
Since the PM has many ACM work - I don't know why because we have a ACM department - the PM has usually not really an idea of the system. So it's my job to keep the technical parts (development, test, technical support and data-center) together.
Cool. What the heck is an ACM???
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
May 9, 2009 at 11:41 am
Paul White (5/9/2009)
Florian Reischl (5/9/2009)
Sorry,:Whistling: I'm saying nothing.
😀
Florian Reischl (5/9/2009)
TPM is "Technical Project Manager" (people like me) in your company.We don't have those. We have small teams - an analyst, someone from site design, a developer, a tester, and a database person usually. Pretty much everyone is equal. We don't even have job titles!
I also don't need this title. It brings up too much meetings... Sometimes I really wish to be just a developer and make software.
Florian Reischl (5/9/2009)
Since the PM has many ACM work - I don't know why because we have a ACM department - the PM has usually not really an idea of the system. So it's my job to keep the technical parts (development, test, technical support and data-center) together.Cool. What the heck is an ACM???
*lool*
I really thought this is an international acronym (usually I really hate acronyms!). It's the "account manager". The person you never saw before who explains you that her/his software will fix the problems you never had. :laugh:
Greets
Flo
May 9, 2009 at 11:52 am
Florian Reischl (5/9/2009)
Nope. The customer!Sure, the tester also found this "feature" (as first) but the TPM thought there is no time to fix it for the first version and the customer "for sure" would never do this...
Ah yes, been there many times. In such circumstances I usually ask the decision maker (TPM in your case) if they had thought about why we were testing things if we weren't going to use the results anyway?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
May 9, 2009 at 11:58 am
RBarryYoung (5/9/2009)
Florian Reischl (5/9/2009)
Nope. The customer!Sure, the tester also found this "feature" (as first) but the TPM thought there is no time to fix it for the first version and the customer "for sure" would never do this...
Ah yes, been there many times. In such circumstances I usually ask the decision maker (TPM in your case) if they had thought about why we were testing things if we weren't going to use the results anyway?
Hi Barry
You are correct. Please notice that this was not my project!!! This project becomes more and more a comedy for me. I'm just playing the viewer from outside. 😉
Greets
Flo
May 9, 2009 at 12:03 pm
RBarryYoung (5/9/2009)
Ah yes, been there many times.
I know. It seems to be the same most everywhere. Kinda depressing!
RBarryYoung (5/9/2009)
In such circumstances I usually ask the decision maker (TPM in your case) if they had thought about why we were testing things if we weren't going to use the results anyway?
The answer, inevitably, is "because you have to test!" together with a frown and a dismissive look.
I used to sometimes try to pursue the logic, but met with extremely limited success.
Now I just let them get on with it 😉
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
May 9, 2009 at 12:23 pm
Paul White (5/9/2009)
RBarryYoung (5/9/2009)
Ah yes, been there many times.I know. It seems to be the same most everywhere. Kinda depressing!
RBarryYoung (5/9/2009)
In such circumstances I usually ask the decision maker (TPM in your case) if they had thought about why we were testing things if we weren't going to use the results anyway?The answer, inevitably, is "because you have to test!" together with a frown and a dismissive look.
I used to sometimes try to pursue the logic, but met with extremely limited success.
Now I just let them get on with it 😉
I have found that as I have gotten older, I am actually having more success at pursuing this with them. Heh, either the ravages of time and age are also lending me some aura of wisdom and gravitas or else I really am just getting better at finding the right button to push ("But Joe, their your testers on your project. If you just ignore it and then it blows up on the customer, you know that some SOB here who wants your job will just use that against you. You've got to CYA, it's the only smart thing to do.") 😀
(and yes, sometimes FUD can be used for good 🙂 )
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
May 9, 2009 at 12:41 pm
Luckily I recognize those acronyms!
Expect questions from Flo 😀
Maybe age has brought patience? I don't hit 40 for another two months so I am still an impetuous youth!
😛
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 15 posts - 61 through 75 (of 82 total)
You must be logged in to reply to this topic. Login to reply