October 11, 2016 at 1:31 am
A few years later on and I feel that little has changed in this arena. There appears to be too much movement in other areas for improvement initiatives for installation to gain any traction.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 11, 2016 at 2:08 am
As developer I don't hate SQL Server at all, I've never met a DBA in person so often have to do little bits and pieces that I guess you'd expect a DBA to do. I don't see how a DBA could ever write the SQL my application needs because they would have to be working on the application and since technically that can never happen because typically I'm involved with products that serve a specific need.
The main problem I see with customer DBAs is they don't want to get involved and make us do all the leg work remotely. But then when they ask can they add an index or make this change or that change, we say no because that could screw up the next upgrade, but if you send us the script that makes the change we will incorporate it after testing they then go silent and we never hear from that person again - sour grapes? just plain arsehole? who can say but that's my experience.
All the projects I work on never use SQL Express always a full version of SQL Server so I guess this isn't really aimed at me because I've never wanted to deploy SQL Express with my application.
I will quite happily write stored procedures, views, UDFs, triggers, schema, constraints etc...
However when it comes to the actual infrastructure things like clustering, failover nodes and all that kind of side of things I'm at a loss.
October 11, 2016 at 7:07 am
Software developers don't like the SQL language primarily for two reasons:
1. It's a minefield of performance issues with many side effects, unlike the object oriented languages most were trained on.
2. It's not an object oriented language.
I haven't heard any dislike for SQL Server from developers, only from managers, who've said:
"Why do we need a DBA to support SQL Server? Why doesn't the server maintain itself like Windows Server?"
October 11, 2016 at 7:22 am
Gail Wanabee (10/11/2016)
Software developers don't like the SQL language primarily for two reasons:1. It's a minefield of performance issues with many side effects, unlike the object oriented languages most were trained on.
2. It's not an object oriented language...
I think that might require a young/new/Object-Oriented Programming trained/uneducated caveat. OOPLs are also a minefield of performance issues...and many of us devs didn't even start with OO. And some of us like SQL. 😉
Gail Wanabee (10/11/2016)
...I haven't heard any dislike for SQL Server from developers, only from managers, who've said:"Why do we need a DBA to support SQL Server? Why doesn't the server maintain itself like Windows Server?"
Windows Server maintains itself? HaHaHaHaHa :w00t: I've got to believe that you were laughing at that one Gail!!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 11, 2016 at 7:42 am
Still good advice even after all these years.
October 11, 2016 at 9:26 am
I thought the addition of attaching to database files directly (in Visual Studio) and having separate environments for Dev, Test, and Production was the current M$ way.
Why would anyone think that building the systems and installing/configuring the software and hardware needed for a Failover or Performance cluster using SQL 2008 R2 is more Frustrating than the same task using SQL 7 or SQL 2000 and the Server products available at that time?
I know (for me) the real frustrating install and deployment was MSDE on Windows CE so the RTOS Inventory handhelds could send and receive updates from the primary database.
October 11, 2016 at 10:06 am
If developers struggle to install and manage SQL Server on their local PC, imagine if they were left to manage the production database server? I guess it's like a DBA trying to configure IIS web applications.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 11, 2016 at 3:49 pm
I think it would be more helpful to say what specific changes for SETUP you would like to see go into the newer versions of SQL as this thread appears to go off on different tangents.
October 11, 2016 at 4:31 pm
TravisDBA (9/8/2010)
You think that is frustrating. I am still waiting for them to put a WHERE clause on a TRUNCATE statement.:-D
Thanks. Made me laugh.
October 12, 2016 at 12:08 am
Having just installed Apache Spark and got it talking to RedShift through PySpark on Python 3 I can tell you that getting to the point of being able to run a fairly simple program has not been easy.
As to installing the library for Python to talk to Postgres without actually installing Postgres itself..... still haven't cracked that one.
Yes SQL Server could have a better install routine but it is light years ahead of some of the data technologies that are emerging.
October 12, 2016 at 1:11 am
PHYData DBA (10/11/2016)
I thought the addition of attaching to database files directly (in Visual Studio) and having separate environments for Dev, Test, and Production was the current M$ way.Why would anyone think that building the systems and installing/configuring the software and hardware needed for a Failover or Performance cluster using SQL 2008 R2 is more Frustrating than the same task using SQL 7 or SQL 2000 and the Server products available at that time?
I know (for me) the real frustrating install and deployment was MSDE on Windows CE so the RTOS Inventory handhelds could send and receive updates from the primary database.
Nowadays when you say M$ you lose all credibility, #justsaying
October 12, 2016 at 8:03 am
Eric M Russell (10/11/2016)
If developers struggle to install and manage SQL Server on their local PC, imagine if they were left to manage the production database server? I guess it's like a DBA trying to configure IIS web applications.
True that.
Installing Visual Studio 2008 and on is super easy is to do.... very wrong and poorly.
There are defaults for everything.
Unfortunately those defaults can truly ruin a good development environment configuration and it's performance.
They also leave you with an install that does not support or still needs to be configured for many of the key features.
Same is true for many other M$ products. At least SQL Server makes a person look before they leap. There are so many good guides and instructions available about an install compared to times before that for me this editorial seems out of place.
Viewing 12 posts - 31 through 41 (of 41 total)
You must be logged in to reply to this topic. Login to reply