June 27, 2016 at 8:03 am
roger.plowman (6/27/2016)
Sean Redmond (6/27/2016)
What's the point of having DBAs if people believe that ORM tools will do it all?Veeam does backup and point-in-time restores.
It seems to me that one side of Microsoft is eating away at the other side. The dot-Net folks seem convinced now that the database belongs to them, rather than to the SQL Server folks. The dot-Net folks design it, create it and use their performance-devouring Entity-Framework to access it. And all the DBAs do is complain, complain, complain.
We are in big trouble.
Maybe. 🙂
Personally, I always thought database design belongs in the developer's hands. Having said that, of course, that makes it the developer's responsibility to do (at least) basic performance optimization and making sure the database architecture uses (at least) sane practices that have some nodding acquaintance with database performance reality.
I always considered the DBA's job to be a second-tier support for database performance issues, as well as the one who tends to the care and feeding of the database (backups, hardware performance tweaks like moving pieces around to different drives, that kind of thing).
As for who "owns" the database (i.e. gets the blame for performance and reliability issues)? That's on the developer.
I've done object oriented programming for years, and interfaced it with databases too. It isn't all that hard, and if an ORM tool can't manage it, well, you're using the wrong ORM tool.
Not that I've ever actually used an ORM...I'm kind of old school that way.
I think it comes down to 2 different types of databases: those that CAN be designed through an ORM, and those that can't 🙂
There are a lot of applications that are simple enough, don't necessarily have a lot of twists and turns and don't have a whole lot of potential to grow out of control. In short a basic application with a basic database to back it up.
That said - throw in a lot of integration, real-time processing or complex data to track and the tools to perform basic designing tend to turn against you. Not that you can't somehow use ORM in complex scenarios, but you usually have to "show it who's boss" (override/replace its implementation, or get it to ignore some items).
The good news IMO is that many of the basic applications end up growing up into much more complex applications which no longer can easily fit within the automated tool parameter.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 27, 2016 at 11:09 am
roger.plowman (6/27/2016)
I've done object oriented programming for years, and interfaced it with databases too. It isn't all that hard, and if an ORM tool can't manage it, well, you're using the wrong ORM tool.Not that I've ever actually used an ORM...I'm kind of old school that way.
Well, clearly you've never used the wrong ORM since you've never used an ORM.
If you ever do use one, you're likely to find out the hard way that every ORM tool is a wrong ORM tool, and the concept the wrong ORM tool is just plain wrong because there it isn't just one that isn't right.
Of course some ORM tools can sometimes get a very very simple database right, but none of them can do a decent job with anything more complex than very very simple, and it's generally possible to find something very very simple that will send them way off the mark.
Tom
June 28, 2016 at 12:21 am
TomThomson (6/27/2016)
...every ORM tool is a wrong ORM tool...none of them can do a decent job with anything more complex than very very simple...
Unfortunately, I find this to be the case too. It is a bit like the cross-platform dev environments in the late 80s/early 90s. Great idea but it just doesn't work out in practice.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 28, 2016 at 12:30 am
I am a developer who has developed a large number of databases of varying complexity from scratch. I have certainly made mistakes but also some of the work I am more than happy with (I think most people here will feel this way).
What has given me an advantage over some peers over time is that at college (this is the UK so we are talking 16-18 year old me) I did a full time computing course that did a good job of covering database theory (normal form etc.) as well as other aspects of theoretical computing (e.g. operational costs of different sorts). Pretty good for what was supposed to be a practical course. Clearly the lecturers and the course writers understood the value of a theoretical background (or at least some).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 29, 2016 at 7:08 am
Over the years I've designed quite a few databases from scratch, several of them not relational, whether because the relational model had not yet been invented or because no working RDBMS was available.
My first try at designing a database (in 1969 or 1970) was a disaster - fortunately it wasn't important.
In the early 70s I designed a few ad-hoc non-relational databases for use as part of the development and release process of software for advaced communications processors (I wasn't going to let my development team do database stuff, I wanted them doing telecoms) and those were all successful and remained in use for several years after I'd moved away to work on mainframe operating systems instead of comms processors, although now with a few decades more experience I would certainly do them differently (maybe even try to fix the development and release processes to eliminate the need for those databases).
I started learning about the relational model in the early 70s, but didn't do any real work (as opposed to playing about) with it until the 80s; and at first even the real work tended to be research oriented and/or implementing stuff to support massively parallel RDBMS (collaboration between ICL and Oracle) rather than designing databases.
Since then I've designed several relational databases from scratch, usually collaborating with an expert on the topic the database was representing but a couple of times I was on my own and had to be my own expert on the topic and on legal data protection and security requirements. Those have been successful. I've also tried to fix databases that someone else designed badly (actually, it looked to me as if they just threw it together without bothering with design, and that applied to the overall system architecture as well as to that database) and no-one thought had thought of using stored procs or parametrised queries or views for everything, all the SQL was written by C++ developers (or generated by C++ that they had written) who hadn't the first clue about databases. Digging us out of that hole was far more demanding than doing the original design myself ever was. I've also done a couple of ad-hoc non-relational databases when a friend has needed a storage component for some personal project.
Tom
June 29, 2016 at 7:13 am
I've designed lots of databases from scratch.
The most important part of the process is to remember that it has to be maintainable and extensible. "Clever" solutions are almost always unmaintainable. Do something standard, not something clever, in your design, and it'll be much, much easier to keep the database working over the years.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 29, 2016 at 8:41 am
I've probably designed a dozen or so. None particularly complex or unusual but they do support business "end to end" so there's normally a lot of different entities to juggle but they're all the usual 3NF stuff.
I have to say, I really don't understand the hostility to ORMs. I designed my DBs using management studio (or more accurately I guess I should say implemented - the design bit's normally done on flip charts and note pads:rolleyes:) for years but have recently begun moving over to Entity Framework's Code First approach. For me it's been a largely positive experience and I've only found a couple of things it couldn't handle for me (and I've been able to cover those with a post build script). On the plus side, Code First Migrations make change control and roll-outs a doddle. I'm not as fluent with it as I am with SSMS yet so it frustrates from time to time but that's improving.
I think part of the difference may be that I'm not looking to it to do the design for me. I've still got to know my theory and I've still got to make the decisions. I suspect ORMs really fail when people expect them to close that knowledge gap for them. If you use them in much the same way as you'd use SSMS they do the job pretty well IMO.
June 30, 2016 at 2:35 pm
maintainable and extensible. "Clever" solutions are almost always unmaintainable
You don't go into details, but I think I have to maintain some solutions you would consider "clever." And yes, they are harder to maintain than a more standard approach.
June 30, 2016 at 2:48 pm
I guess if you're forced to do something "clever" then you have to document your code inside the code... not in some "book" somewhere that nobody can find. (Yeah, I've seen one of those... it was a nightmare)
June 30, 2016 at 2:52 pm
pietlinden (6/30/2016)
I guess if you're forced to do something "clever" then you have to document your code inside the code... not in some "book" somewhere that nobody can find. (Yeah, I've seen one of those... it was a nightmare)
I can't count the number of times I heard about "self-documenting" code! I have to keep reminding people that the code can only show you WHAT was done but not necessarily WHY it was done!
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
Viewing 10 posts - 31 through 39 (of 39 total)
You must be logged in to reply to this topic. Login to reply