July 31, 2008 at 9:46 am
Who is responsible for good database design and documentation when programmers are using these ORM tools that trivialize creation of the DAL? Very clever programmers with not much understanding of DBMS performance issues are creating a pile of CRUD. That's OK, they say, the data is persisting hibernating in the database. Application developers-- you do not own the data and it is not up to you to decide what database permissions there are.
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
July 31, 2008 at 9:51 am
The Almighty Data Architect is in charge 😀
Thou shalt obey his words both developer and DBA alike or suffer in the purgatory of unemployment!
:D:D:D:D:D:D:D:D:D:D:D:D
Hiding under a desk from SSIS Implemenation Work :crazy:
July 31, 2008 at 10:00 am
A good DBA **is** the data architect because she understands ER, DBMS performance, and SQL Server sysadmin.
What? says the app developer, commit to a specific DBMS platform? Yes, says the DBA-- that's better for the organization than committing to a melange of code knit together with Visual Studio. It's easier to move a database from Oracle to SQL Server than it is to change any major part of an application that has been created with "whatever works."
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
July 31, 2008 at 10:34 am
katesl (7/31/2008)
A good DBA **is** the data architect because she understands ER, DBMS performance, and SQL Server sysadmin.
I disagree with this statement completely. Its the same as a "good" developer can be the DBA. Its 2 completely different methodologies and skill sets.
DBA's implement what an architect specifies. An architect works at the logical level, not the physical.
July 31, 2008 at 10:48 am
Of course a DBA works at the logical level. That's what ER diagramming is. Application developers who aren't at all familiar with ER diagramming? No wonder... Some people think a DBA is simply a database backup technician. No way should a backup technician job be given the job title DBA.
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
July 31, 2008 at 11:17 am
katesl (7/31/2008)
Of course a DBA works at the logical level. That's what ER diagramming is. Application developers who aren't at all familiar with ER diagramming? No wonder... Some people think a DBA is simply a database backup technician. No way should a backup technician job be given the job title DBA.
DBA - Database Administrator. Nothing in that job description even comes close to what an architect does. DBA's implement Architects designs, troubleshoot, code, tune, and yes backup and disaster recovery.
Your idea of blending the architects role with the DBA is just as bad as blending the developer and DBA roles.
July 31, 2008 at 11:29 am
Which job role does the ER diagramming? The DBA job title **started** with ER diagramming 25+ years ago. Why should the DBA hand over ER diagramming to a programmer who is now called "architect" by virtue of understaning n-tier and scalability? Or does the architect think she can be an architect without doing any ER diagramming?
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
July 31, 2008 at 11:32 am
katesl (7/31/2008)
Which job role does the ER diagramming? The DBA job title **started** with ER diagramming 25+ years ago. Why should the DBA hand over ER diagramming to a programmer who is now called "architect" by virtue of understaning n-tier and scalability? Or does the architect think she can be an architect without doing any ER diagramming?
I never said, nor have I heard anyone else say the architect is the programmer? And since when does ER diagramming become the defining role of a DBA, Architect or a programmer?
If your gung ho about drawing pictures, feel free. But it is the architects responsibility to design, the DBA AND programmer's job to implement. Regardless of who draws the pretty pictures.
July 31, 2008 at 11:54 am
phew
Good thing my title is Database Architect/DBA!
July 31, 2008 at 11:56 am
Anders Pedersen (7/31/2008)
phewGood thing my title is Database Architect/DBA!
No, the good thing is that your company is willing to have someone in the position LOL... too few see it as a necessity. 😀
July 31, 2008 at 3:26 pm
maybe someone mentioned it already in this quickly growing thread, but for me one huge benefit of procs is maintenance.
if you use procs exclusively and don't allow ad hoc queries from clients, then you don't have to worry about who might break when you need to make changes to the underlying tables (which WILL happen in any system that lives for a while).
if you have unknown, crufty old apps out there executing ad hoc queries against tables and views directly, you'll can never really be sure if your changes will break them or not, because you don't know what query they are executing.
if all access is through procs, the stuff that could break as a result of your changes is limited to procs only. nice thing about that is they are stored on the server, not on random clients sprinkled throughout the enterprise.
In all programming, database and otherwise, one should strive to provide a minimal, but complete interface. exposing all tables to clients is complete, but it's hardly minimal!
---------------------------------------
elsasoft.org
July 31, 2008 at 7:49 pm
I prefer to use stored procedures whenever possible to do so. My main reason is for maintenance and tuning. I have an application that do not use SP at all. The problem arises when the application run slower than expected. After fixing missing indexes just to find out that some of the SQLs are not properly written. It is very bad since I am not the one who created the app so I do not know where those SQLs come from. Just need to live with them. 🙁
Ivan Budiono
July 31, 2008 at 8:11 pm
Thank you, previous poster.
I would bet the author of the app that creates slow-running SQL who knows where (1) says "I would never let **users** run ad hoc queries against my app's database"; and (2) thinks ER diagrams have no use for database design, that they are "pretty pictures."
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
July 31, 2008 at 10:41 pm
Give 'em hell katesl. DBA <> doofus.
I've had "architects" hand off some of the goofiest architectures that they expected me to implement without any question. I guess it was because they had more letters in their title. It matched the class diagram perfectly and had such handy column names as ID and Name. That works well in an OO polymorphic world, but having to alias most column makes for interesting debugging.
What works well in application code will, quite often, stink in a database. Database design isn't magic but good database design can help make magic happen.
The biggest issue facing all of us is to know the tools of the trade and how/when/where to apply them. You must understand what problem is being solved. If you want portability then Java and ANSI-89 SQL is the way to go. Just don't expect stellar performance. Developing for portability means you can't take advantage of any of benefits of the underlying database engine. Simple stuff such as GetDate (SS) or SysDate (ORA) will fall by the side as will all the more useful functions.
It's never good when you can brag that your app runs like cr@p on five different platforms -- but boy is it portable.
--Paul Hunter
August 1, 2008 at 1:45 am
Thats why as I posted earlier you build a seperate optomized DAL part for each db. 😉
That way you have abstraction and performance with the stored procs in each db implemented and tuned for performance. 🙂
Data Architecht - not a team player - sack 'em they are no good at their job.
Application design is a team activity - multiple input and iteration - not doing this leads to crap software. 😛
Go build some n-tier (at least 3 = n) software e.g.
Client(web/fat) - Middleware (ORM/DAL) - Database(stored procs) 😀
ORM can map to stored procs 😉 look at LINQ
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
Viewing 15 posts - 106 through 120 (of 160 total)
You must be logged in to reply to this topic. Login to reply