Search results matching tags 'SQL Server', 'Rant', and 'DBA'http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&tag=SQL+Server,Rant,DBA&orTags=0Search results matching tags 'SQL Server', 'Rant', and 'DBA'en-USCommunityServer 2.1 SP2 (Build: 61129.1)Code that Writes Code - A Good Idea or Not?http://sqlblog.com/blogs/buck_woody/archive/2010/02/16/code-that-writes-code-a-good-idea-or-not.aspxTue, 16 Feb 2010 14:14:00 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:22348BuckWoody<P>I’m a big fan of code that writes code&nbsp;– most of the time. For instance, whenever you use the “templates” feature in SQL Server Management Studio (SSMS) or the Maintenance Wizard, you’re using code that writes other code. There’s even a trick of writing Transact-SQL (T-SQL) code that in turn creates other code.</P>
<P>But there is a class of code that writes code that I’m more cautious about. Whenever a program “automatically” generates a database schema, I begin to get nervous. No, I’m not talking about Entity Relationship Diagram (ERD) tools such as those from Quest and Embarcadero, I’m talking about things like NHibernate and other coding paradigms that “abstract” the database layer away from the developer. </P>
<P>I have two&nbsp;reasons that&nbsp;I’m not impressed with these&nbsp;programs and paradigms. </P>
<P>First, they do not take the entire solution into account. As data professionals we learn our platform (whether that’s XML, flat files, SQL Server, Oracle, IBM, whatever) and we study how each of the features maps to a complete solution. I might choose to use Replication, Service Broker, Clustering, FileStream, or any number of features to completely remove the need for code in that area. And by making those choices,<EM> I change the design of the database accordingly, based on the</EM> <EM>solution</EM>. The abstraction tools don’t&nbsp;– they just spit out the same Data Definition Language (DDL) statements they know how to create, without thinking about maintenance, speed, reliability or anything else. </P>
<P>When I mention this to the developer, they say “just put that in later”&nbsp;– and that’s the beginning of woes for the data professional. Most of the time you <EM>can’t</EM> put things of a fundamental nature in later. In some cases, it’s a complete tear-down and re-write of the entire database. Very painful, and something you never want to experience.</P>
<P>The second main reason that I am skeptical about tools that automatically create DDL statements to create databases is that they don’t do a good job. Once again, this is because of a holistic view&nbsp;– the tool doesn’t have the capability to take everything into account, including the data pattern, so it has no idea how far to normalize, where to put files and filegroups, what kind (if any) indexes are needed, or when to choose between a natural or surrogate key. </P>
<P>Is all this just because I’m a DBA, and anal about my databases? No. It’s a <STRONG>business</STRONG> problem, because these tools continue to separate the DBA from the Developer, and both from the Business Analyst. And it's the business that suffers when developers (or DBA’s) take shortcuts. I wonder how much time and money are wasted in business re-writing databases because&nbsp;of a&nbsp;shortcut using poor tools?&nbsp;</P>
<P>So let’s do the hard work&nbsp;– let’s let the business requirements dictate the solution, rather than the other way around. Even for the “little” databases, which of course never stay that way.</P>
<P>Now, does this mean I hate NHibernate or the Entity Framework? Not at all!&nbsp; Just work <EM>with</EM> your data professionals instead of <EM>without </EM>them. You’ll find that by bringing the best practices of these ORM tools together with a well-designed database, you’ll deliver a solution to the business that is fast, reliable and safe. Isn’t that what we all want?</P>Spit it out already!http://sqlblog.com/blogs/buck_woody/archive/2010/01/06/spit-it-out-already.aspxWed, 06 Jan 2010 14:11:11 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:20617BuckWoody<p>You’ve probably seen that commercial where the chewing-gum company van stalks the guy who has been chewing the same piece of gum too long, and they attack him and make him chew another piece.</p> <p>I feel like that with SQL Server 2000. Almost every shop I go into has at least one primary application running on SQL Server 2000. Now, don’t get me wrong – SQL Server 2000 is a fine piece of software engineering. From over TEN YEARS AGO. In “software time”,&#160; that’s like a thousand years or something. </p> <p>While it was great for its day, the newer versions are faster, more secure, and more robust. And every time it doesn’t get upgraded, SQL Server is perceived as “not as fast/strong/etc” as other platforms (which <em>are</em> upgraded, of course).</p> <p>Now, I’m not suggesting that anyone upgrade for upgrade’s sake. We all have work to do, and the last thing we need to do is change out a platform when there’s no need. </p> <p>But there is a need. SQL Server 2000 isn’t in mainline support any more. That means it can be attacked easier and so on. And it doesn’t scale like the new offerings, nor does it have any of the new features the latest versions have. </p> <p>“Oh”, you might say, “I don’t use those features anyway.” Well of course you don’t – you can’t if you still have SQL Server 2000! How do you know the ways you could help your organization if you don’t experiment with the new stuff?</p> <p>But it isn’t the DBA I would chase down and steal gum from. It’s the <em>vendors</em>. </p> <p>Every time I raise my eyebrows when I hear about the SQL Server 2000 installs, the DBA shrugs and says “The vendor won’t certify SQL Server X, so we have to stay at SQL Server 2000 or 2005.” And I say, that’s just <em>lazy</em>. Unless the vendor codes specifically for deprecated features, a simple test run during their software development should allow them to move forward. I’m not saying that’s an easy task, but certainly they’ve tested their software releases once in the last ten years, no? If not, doesn’t that make you nervous?</p> <p>Anyhoo, spit out the SQL Server 2000. Or I might have to fire up the company van.</p>Aren’t DBA’s Just System Admins for Databases?http://sqlblog.com/blogs/buck_woody/archive/2009/11/30/aren-t-dba-s-just-system-admins-for-databases.aspxMon, 30 Nov 2009 16:37:32 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:19335BuckWoody<p>Last week I ran into an argument I’ve had since I left the mainframe space decades ago. A developer told me “DBA’s don’t design databases.” The inference was that DBA’s (i.e., Database Administrators) only worry about hardware, security, OS, database backups, things like that. He seemed amazed that a DBA would ever do “data” work.</p> <p>It may be the name. Perhaps the “admin” part confuses developers. Also, it is true that in some shops, a systems admin does double duty with Windows, SQL Server, and perhaps even mail and web admins. </p> <p>But there are a LOT of DBA’s, or as the term I like to use, “Data Professionals”, that actually DO get down in the trenches and design databases, write Transact-SQL code and stored procedures, and do almost everything in the database other than write middle-tier or User Interface (UI) code. Some I know even do that.</p> <p>So what if there is a miscommunication on this? Well, the ramifications can be huge. For one thing, there’s a lack of respect. That’s not called for ever, no matter what anyone’s role is. Also, one of the most impactful areas in a database is the design. When a DBA is asked to export data, tune a process, or troubleshoot an issue, it invariably involves the design. So when a DBA doesn’t get to do the design, they have to live with the results. And anything you’re responsible for when you don’t have the authority over is a recipe for stress.</p> <p>Another issue is that DBA’s “inherit” all kinds of data structures form around the company. From Microsoft Access to Excel, to amateur Business Analysts creating databases in the Express Editions, they deal with bad design day after day. The newer “modeling” languages that are coming into vogue will make this problem much worse. These languages do not take scale, extensibility, security or performance into account – they just make sure that the data ends up in the right place for that particular design, which is a recipe for data disaster when the “small application” the developer writes becomes a “mission critical” system the DBA has to troubleshoot at 2:00 A.M.</p> <p>So in case you’re a developer, and in case you think DBA’s “just do admin” – think again. DBA’s spend their whole day in this world, and can be a valuable asset to your development efforts. Bring them in early, bring them in often, and whatever you do – don’t design alone. Business Analysts, Developers and Data Professionals are needed to make a good, sustainable, secure, well-performing database.</p>