January 23, 2015 at 10:19 am
Andrew..Peterson (1/23/2015)
Sadly - that is NOT a very good sign. Other than PASS, where do they get their insight?
Now, if a company has a product that is not listening to their customers, raising prices, and generally just not caring, what does that tell you?
We'll it was a great run, and yes, I do agree that it will be around for awhile, but will anyone be using it for new projects? new startups?
When I was at your seminar in Cambridge, all the attendees were our age. Does anyone remember COBOL?
You have to remember that SQL Server has a large user base. For every one of us that says "fix SSMS", there are plenty of people saying "add in memory tables" or "make BI better". They (MS) listen, and they don't.
They're still selling lots of SQL Server, so in some sense, is it a problem if they raise prices? I think in the long term it is, but I also accept that maybe I'm wrong.
January 23, 2015 at 10:21 am
xsevensinzx (1/23/2015)
That's a pretty bold and general statement about open source that as someone said, depends on the situation. I mean, I use open source all the time. I use open source (python) to work with SQL Server because it's like magic, especially when your using your data for analytics and CAN'T afford additional money sinks into SAS. If I did the same thing in Microsoft technologies, it would likely take me more time versus Python for the simple fact that Python is a rapid prototyping language that is designed for speed in development.
I guess this depends. If you are doing new development, and you know OSS tools, then perhaps it's not hours of development. If you're porting your app from SQL Server to anywhere, then it is. Even simple ports take time, and any line of code you have to chance can be hours with dev/test/deploy.
The time factor also has to do with skill. I don't know much Python. Likely it would take more more time than using something else, but I'd also learn. So it's an investment for payback later v now.
Certainly not an easy question, but it's not clear either way that you can do more than generalize on which might be better for anyone.
January 23, 2015 at 10:36 am
A single SQL Server Enterprise instance running on a moderately powered server can house multiple OLTP applications for even large organizations. I've seen cases where organizations are using multiple instances of Enterprise Edition to do things like QA or staging, when they could get by with a single well tuned EE instance or offload just the ETL staging tier to something like MySQL or a low end server with Standard Edition.
Where the economics of SQL Server totally doesn't work is when startups, universities, or corporate skunkworks teams are trying to warehouse Big Data on a very limited budget. For one thing, there is often times simply no profit in the endeavor. But that's a niche corner of the database world.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 24, 2015 at 12:56 am
Steve Jones - SSC Editor (1/23/2015)
xsevensinzx (1/23/2015)
That's a pretty bold and general statement about open source that as someone said, depends on the situation. I mean, I use open source all the time. I use open source (python) to work with SQL Server because it's like magic, especially when your using your data for analytics and CAN'T afford additional money sinks into SAS. If I did the same thing in Microsoft technologies, it would likely take me more time versus Python for the simple fact that Python is a rapid prototyping language that is designed for speed in development.I guess this depends. If you are doing new development, and you know OSS tools, then perhaps it's not hours of development. If you're porting your app from SQL Server to anywhere, then it is. Even simple ports take time, and any line of code you have to chance can be hours with dev/test/deploy.
The time factor also has to do with skill. I don't know much Python. Likely it would take more more time than using something else, but I'd also learn. So it's an investment for payback later v now.
Certainly not an easy question, but it's not clear either way that you can do more than generalize on which might be better for anyone.
Yeah, but that's factoring in your skills at knowing a piece of technology or not. That's for all technology, not just OSS. SQL Server has a learning curve just like everything else. And to be more technical, OSS is in a lot of cases going to be a lot more flexible than the other. Due to that, you can surely find yourself going down a rabbit hole, but that's ideally the freedom some people want. More freedom to remove restrictions that are blocking you. Not just about recreating the wheel or saying things like you will lose more hours with OSS versus not using it.
But, we are really comparing apples to oranges here in regards to python and SQL Server. 😉
January 24, 2015 at 5:59 am
Andrew..Peterson (1/23/2015) Does anyone remember COBOL?
Have you seen the contract rates for COBOL programmers!!!!!
Do I remember COBOL? Everytime I look at a NOSQL document database.
January 26, 2015 at 8:08 am
David.Poole (1/24/2015)
Andrew..Peterson (1/23/2015) Does anyone remember COBOL?
Have you seen the contract rates for COBOL programmers!!!!!
Do I remember COBOL? Everytime I look at a NOSQL document database.
Exactly! Sometimes I think technology is like the fashion industry.
Just wait a while, and bell bottoms will be back in fashion.
Alas, I have not looked at: COBOL, assembler, etc. since college.
The more you are prepared, the less you need it.
January 26, 2015 at 11:51 am
The thing is the people that are most likely to switch are probably the ones that don't contribute as much to the revenue stream. Oracle is able to make lots of money on its products simply because of the inertia of what was developed around it and that it targets large companies. Microsoft is looking to do the same thing, but at a slightly cheaper price.
The unfortunate side-effect of this is that small companies end up getting squeezed out.
January 31, 2015 at 12:23 pm
I saw an amazing article on how Oracle would save hundreds of thousands of dollars per year because the tooling was so much better that it took Oracle DBAs 10 seconds less to do a job.
In the appendix to the article it listed the tasks involved. Creating a user using the GUI, creating a table using the GUI..etc
I know a few Oracle DBAs and loads of SQL DBAs and their reaction was one and the same. I don't create users very often, let alone often enough for it to make a blind bit of difference to my cost. What sort of DBA creates tables using the GUI?
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.
February 2, 2015 at 7:39 am
David.Poole (1/31/2015)
I saw an amazing article on how Oracle would save hundreds of thousands of dollars per year because the tooling was so much better that it took Oracle DBAs 10 seconds less to do a job.In the appendix to the article it listed the tasks involved. Creating a user using the GUI, creating a table using the GUI..etc
I know a few Oracle DBAs and loads of SQL DBAs and their reaction was one and the same. I don't create users very often, let alone often enough for it to make a blind bit of difference to my cost. What sort of DBA creates tables using the GUI?
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.
:Whistling::discuss:
(marketing department blowing dope smoke)
I could easily picture a federal government contractor billing $500 each time they receive a ticket to create a new database login account. That's no joke. But regardless of whether it's Oracle or SQL Server, it requires only a couple of minutes tops. Most commercial SOA hosting services provide a web based GUI allowing the customer to create their own logins.
If an organization is creating thousands of database login accounts on their internal servers, then it's probably licensing where they can potentially save hundreds of thousands of dollars a year.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 2, 2015 at 8:27 am
David.Poole (1/31/2015)
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.
I think you'd be surprised at this. So many of the DBAs I've known use a GUI, especially when they're trying things out. They find it easier to click to add or remove, and I tend to agree. It's a human things that's easier than typing.
However, as you said, you rarely do this. I think that's one reason so many people don't script. They point and click. When they get busy, though, I think that they end up slowing down if they haven't scripted a repeatable process.
But most don't. I've watched Oracle DBAs that had 15 years of experience not run a script with a parameter, but rather type the equivalent of "create login xx for yyy" rather than "Createuser.PS1 'Steve@steve.com'"
February 5, 2015 at 3:01 pm
Steve Jones - SSC Editor (2/2/2015)[hrI think you'd be surprised at this.
Absolutely gobsmacked!
In development I can understand it if it is part of a learning exercise.
In production I could understand triggering a failover.
Any serious changes then I'd feel like I was playing Russian Roulette.
February 6, 2015 at 1:59 pm
I finally read the book, had it on my list for too long! Interesting to think about timespans beyond a lifetime.
February 10, 2015 at 1:25 am
Steve Jones - SSC Editor (2/2/2015)
David.Poole (1/31/2015)
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.I think you'd be surprised at this. So many of the DBAs I've known use a GUI, especially when they're trying things out. They find it easier to click to add or remove, and I tend to agree. It's a human things that's easier than typing.
However, as you said, you rarely do this. I think that's one reason so many people don't script. They point and click. When they get busy, though, I think that they end up slowing down if they haven't scripted a repeatable process.
But most don't. I've watched Oracle DBAs that had 15 years of experience not run a script with a parameter, but rather type the equivalent of "create login xx for yyy" rather than "Createuser.PS1 'Steve@steve.com'"
This is where MS Exchange did an excellent job of being the first MS server software to support PowerShell. The Exchange team altered all of the MMC Snap-Ins to call the PowerShell cmdlets to perform any work. On top of this they added script boxes to the GUI allowing the Exchange admins to setup an action in the GUI that generated a script that they could copy and paste. This allowed the Exchange admins to learn the PowerShell view of their administrative tasks and when generating a script they could check elements against generated output.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 8, 2018 at 12:23 am
I've thought about the cost of switching too.
It comes down to resources.
If you have time, say 5 years and some people (DBAs, developers & sysadmins) whose time can be invested in, say, a PostgresSQL system, then it makes perfect sense to try it out a lesser productive system. The small team acquires the experience of bringing a productive system live and maintaining it. If all are happy with the results, the team can train others once the decision has been made to embark on a more ambitious system.
SQL Server has a very wide-ranging feature-set and if it is extensively used, then migration to other systems is hard. However, if your system is primarily relying on the database engine, then other DBs (like PostgresSQL) become valid alternatives.
It also doesn't help if the new features being introduced by Microsoft are half-baked or so filled with gotchas that you reget halfway through having ever listened to Microsoft's marketing in the first place.
November 8, 2018 at 12:32 am
Steve Jones - SSC Editor - Monday, February 2, 2015 8:27 AMDavid.Poole (1/31/2015)
Real DBAs script things because their tasks have to be reliable and repeatable across many environments. Ditto rollback activity.I think you'd be surprised at this. So many of the DBAs I've known use a GUI, especially when they're trying things out. They find it easier to click to add or remove, and I tend to agree. It's a human things that's easier than typing.However, as you said, you rarely do this. I think that's one reason so many people don't script. They point and click. When they get busy, though, I think that they end up slowing down if they haven't scripted a repeatable process.But most don't. I've watched Oracle DBAs that had 15 years of experience not run a script with a parameter, but rather type the equivalent of "create login xx for yyy" rather than "Createuser.PS1 'Steve@steve.com'"
I don't script for ad-hoc activities. As an example, we have a new data-science guy and I helped set up his work-environment, his sandbox, so to speak. He had forgotten one database and I restored that by GUI, although I could have as easily scripted it.
Later on, he was granted read-access to one of our reporting servers. Normally all users have access by virtue of their Active Directory Groups. Since he was a new category and wasn't in one of the usual AD groups, I created a login for him, again by GUI.
When there is a need for repeatability and consistency, then scripting and automation are the way to go, but for once-offs, the GUI is fine.
Viewing 15 posts - 31 through 45 (of 54 total)
You must be logged in to reply to this topic. Login to reply