June 8, 2013 at 12:43 am
Comments posted to this topic are about the item When Windows don’t provide illumination
Best wishes,
Phil Factor
June 9, 2013 at 1:30 am
Sorry, MS Access and 'those fripperies' is where I come from. It is regretable that SSMS's query creator isn't as polished as Access's. I have absolutely no idea why anyone would WANT to create a table through text and not a GUI. It's like coding HTML in notepad or anything in VI. You can do it, but why? Especially when you can use the GUI to generate a script which you can then tweak. Generally, for VBA recordset SQL, I'll use the query editor to build and test the SQL, and copy-and-paste the SQL into code for tweaking. Why would I want all my fat-fingered typos in my code when I have the tools to avoid them--and be way faster to boot?
June 9, 2013 at 9:22 pm
MS has done a fine job of getting in the way of writing concise SQL statements. ADO.NET Entity Framework is a very dangerous technology in the hands of developers who don't have any interest in the sql that is dynamically generated. The move to cloud based services should rectify most of this nonsense. It going to be hard to justify paying a significant hosting bill as a result of the poorly written code that some of these gui tools produce. No one at MS really mentions it but these poorly designed statements have no chance at scaling.
June 10, 2013 at 1:38 am
I couldn't agree more, as a C# dev. Only the other day I had to sync two database schemas and the auto-generated primary key names were a pain when creating a script to rename across multiple deployments! However it did provide the opportunity to delve into the information_schema table in order to solve the problem. 🙂
June 10, 2013 at 4:36 am
I think your solution is clearly a better implementation.
I think MS in particular has sometimes just fallen short when polishing off the UI implementation of otherwise good ideas which is why I think people like Apple and Google have managed to gain grounds in emerging markets their UIs tend to be smoother albeit more general. I do believe in the principle behind their ideas though and frequently use the diagramming tool albeit often editing generated syntax afterwards.
I always find it slightly amusing when people separate text from graphics/diagrams - in a very real sense they are one and the same. Maybe we just need time for the really valuable non text gui principles to be established we benefit from the ground rules for text which have been established over 3,000 years of history.
I had a look at the new features of Data Explorer in Excel 2013 at the weekend and they're introducing multiple tabs marked things like Query / Pivot table / Data mining etc. Excel is becoming a query editor. They're even introducing a new hybrid query language - M - Personally I would have liked them to align any query language in Excel with TSQL and I would like to have very clear deliniation between textual query editor and the associated graphical editor which generates that text and not multiple variations of a couple of ideas. Similarly aligning the query editor in Access with TSQL always seemed like a good idea. To some extent the departments in MS struggle to coordinate things sometimes.
cloudydatablog.net
June 10, 2013 at 5:58 am
I liken writing SQL vs using designer tools to driving a standard transmission vs an automated transmission. With a standard, you have more control over how the vehicle operates, and likewise, when you write your own SQL rather than have some designer write it for you, you have more control over what the DDL is doing. Sure, you can have a designer do it for you and then tweak it, but are you really looking at all the automated ~decisions~ the designer is making for you, or are you saying "well, the designer put it there, so it must be ok" and ignoring it. If the latter, that, to me, shows a lack of curiosity and ultimately a lack of understanding. Even if you make sure to understand every part of the auto-generated SQL, I argue that this still takes longer. When you need to change a check constraint, I had a dev spend 30 mins trying to figure out how to get the designer to change it and then generate the SQL, and when he had trouble with this he came to me. I wrote the ALTER stmt in less than 2 mins. I don't mean to be too harsh on those who "grew up" doing it that way, but you exercise and strengthen your brain muscles more effectively when you make an effort to figure out how to write the stmt without a GUI to help.
-VG
p.s. I've been coding long enough that yes, I wrote my first HTML in notepad as there weren't many IDEs back in the early 90s. While I agree that having IDEs are helpful, I don't think I would have learned nearly as much if I had not had that original experience of having to figure it all out by trial and error.
June 10, 2013 at 6:44 am
"When they need to construct a class in C#, they don't heave out a prosthetic GUI to do it. They just cut code"
Well, I think one could call Visual Studio the epitomy of a "prosthetic GUI". And I think that's what most c# devs would heave out (appropriate choice of word there I think 🙂 ) when they need to write code.
June 10, 2013 at 9:15 am
I found I quite liked HeidiSQL, the GUI that ships with MariaDB. It echos the commands that the GUI performs including those that are used by the GUI itself during its normal operation. It's quite a good teaching aid.
I think what we really need is a good hard look at intellisense. In SQL Management Studio intellisense is playing catchup with Red-Gate SQL Prompt but SQL Prompt isn't perfect.
As ever the technical problems are easy but there are two business problems to address.
1. Getting cheque signed to buy an intellisense solution
2. Make the development of an intellisense solution a viable business operation.
The writing of SSMS plug-ins is a bit of a black art. Perhaps Red-Gate could help out here.
1. Set up a plug-in writing competition
2. Provide the basic framework for a plugin so the actuall plug-in itself is a //TODO in the provided framework.
June 10, 2013 at 9:59 am
I couldn't agree more. I hate the "noise" generated by SQL Server's reverse-engineering.
I've been coding RDBMS (IBM'S DB2, Oracle, SQL Server) code (DDL and DML) for 30 years. I still use a plain text editor vs. reverse-engineering stuff to check into the source code control system. Yes, I learned long before the fancy GUI "helpers" came about.
Typing it (actually, mostly copy-and-paste with some "find"/"replace" changes) requires me to think about what I'm doing and results in a better (and neater, for SQL Server) end product (DDL script).
I have been badly burnt, to many times to know better, by reverse-engineering software (from numerous vendors). Including a major issue where Microsoft's SQL Server reverse-engineer (generate script) failed to include a CHECK constraint in the resulting DDL. Therefore, I don't trust any of them.
June 10, 2013 at 4:29 pm
I do not understand the point of this Editorial. I do not know anything about the the GUI tools in SSMS for creating tables, but I am familiar with both MS Access and ERwin. For SQL Server databases, I always model database changes in the ERwin file first. I then use ERwin to generate the SQL code which I run in SSMS when appropriate.
Using ERwin, a GUI tool for creating tables if ever there was one, helps me make sure I use consistent code for creating tables. The assistance is huge, and I can't imagine wanting to waste time writing all that code by hand when ERwin will do it for me. I get to focus on the important things like table and join designs. I don't have to worry about whether certain 'code' fields are typically varchar(10) or was that 11? Did I spell that field name correctly? And did I remember to index the foreign key? Etc.
Then there is the documentation. I can write tons of documentation for individual tables and fields in ERwin. Again, I can't imagine putting that documentation only in text files which I then run in SSMS.
All of that assistance from ERwin was vital when I was a newbie. I would have made a ton of mistakes in my database designs had I not had ERwin available when I first started working with databases. I would go so far to say that ERwin was partly a career maker for me. How could a well designed GUI tool for making tables *not* help a beginner? For one thing, you can design all sorts of table and have the tool generate the SQL for those tables. It is how one can learn to write good CREATE TABLE statements.
While I can easily understand finding serious fault with a poorly designed GUI tool, I can't figure out why anyone would put down all GUI tools on principle--especially for beginners. It doesn't make any sense to me.
June 10, 2013 at 7:35 pm
JJ B (6/10/2013)
I do not understand the point of this Editorial. I do not know anything about the the GUI tools in SSMS for creating tables, but I am familiar with both MS Access and ERwin. For SQL Server databases, I always model database changes in the ERwin file first. I then use ERwin to generate the SQL code which I run in SSMS when appropriate.
I used the MS Access GUI tools early on. I eventually found they left me with as bad a design as the designer (me) could come up with.
As far as ERWin, I've never had a chance to use it. And many others haven't either. In many companies the DBA is an accidental one with the job thrown at a sysadmin or a developer that had the job thrown at them. The add-on tools are too expensive or not known about. So the DBAs only have the SSMS tools to use.
Then there is a generation of us that didn't have GUI's to really work with. I started in SQL 7 in the late 90's. You had to code by hand no matter what to get to the extended stuff to start with.
So you are now sitting here and saying that you don't think it is valuable to know how to do it by hand just lacks weight with me. There should always be the ability to do it by hand. Without the basics, the rest is shifting sands.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
June 11, 2013 at 10:33 am
So you are now sitting here and saying that you don't think it is valuable to know how to do it by hand...
That's not what I'm saying. What I'm saying is that 1) it *is* very valuable to have the GUIs despite what the post said, and 2) that the good GUIs help beginners learn "how to do it by hand" correctly. I'm also saying that once you know how to do something by hand, always doing it by hand is generally a waste of time and unnecessary point of possible errors if a GUI is available.
I hear you that not everyone is lucky enough to be able to work with a good GUI tool. That's too bad. I can't imagine wanting to work in such a place. I believe in having the tools available to do a job efficiently. Too bad ERwin is ridiculously expensive.
Jim, thanks for showing how my previous post was not clear. I hope this post clarifies my thoughts.
June 11, 2013 at 11:13 am
Another case where the SSMS GUI failed...
Bug in SSMS where page level locking is disabled.
Whereas, if the SQL DDL command to create the index was coded by hand, the coder would know exactly what they were doing.
And when the object was reverse-engineered, so that it can be properly checked into the source code control system, was this error by SSMS going to be detected? I doubt it.
June 11, 2013 at 11:21 am
I do not understand the point of this Editorial. I do not know anything about the the GUI tools in SSMS for creating tables, but I am familiar with both MS Access and ERwin.
@jj B If you do not know anything about the the GUI tools in SSMS for creating tables, then you would certainly wonder why I'm warning of the dangers of relying on them rather than learning how to cut your own code. What I was trying to say was that we shouldn't rely on the GUI tools. I'm not advocating taking away all the tools that help with database design, just making the point that we should also support the use of code to design databases by providing good documentation and examples.
I'm pleased that you're happy with ERwin. I used it for many years, but I never regretted learning how to cut tables in code as well. For a start, I can use the latest features of SQL Server without having to wait for the ERwin upgrade!
Best wishes,
Phil Factor
June 11, 2013 at 11:34 am
Phil Factor: Thank you for your reply. That makes sense. And concerning waiting for new SQL Server features to get into ERwin: you have me there!
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply