The most important person on any development project is usually a DBA. Good DBAs can save a project - simply because THEY know what they're doing and can create a performing database and schema.
Historically SQL Server databases have always suffered from developers tinkering and building themselves a database. This is due to the toolsets of SQL Server being easy and enabling folks (who shouldn't) create an applications database. Oracle on the other hand has always suffered from inadequate tools (ported over from Unix) which developers DON'T understand. Oracle systems tend to have dedicated DBAs - simply because they're the only ones that understand Oracle i.e. TOAD. In consequence Oracle systems tend to be better designed that SQL server (in general) As far as business logic is concerned I would say you have to consider several factors: Is the business logic reusable by other applications Does the business logic require additional database access i.e. update, inserts etc Does the business logic require reference relationships i.e. domain model If the logic is reusable then it may be worth considering placing that logic in the database If the business logic is chatty with the database it may be worth putting the logic in the database to reduce roundtrips Domain models can be better than relational ones - if you require a domain model - you can't do it in the database (unless you use SQL Server 2005) I've been involved in systems (Dell for example) where we've placed ALL logic into Oracle packages to improve performance. Reason for doing this was because the application was simply pulling data into the middle-tier massaging it and then putting it back into a different set of tables. We decided that rather than take the hit of the network hops we'd put all the work in the database - we couldn't have done this had we not had an Oracle DBA. Some food for thought - GRID, or more precisely Oracle 10g - the idea here is to run a Oracle in a GRID architecture i.e. many nodes, which makes the system very scalable - using their own I/O disk/file technology makes Oracle 10g a very fast database with potentially each query being serviced by a single node - much like Google (which has 100,000 machines worldwide) Performance in databases is usually due to locks which hurt/kill concurrency. Well designed databases will scale and perform - ultimately it depends on how much money you have 0 but if you keep locks for too long you'll kill the system. Andrew Gayter Developmentor Instructor .NET Architecture and Design http://www.develop.com/us/training/course.aspx?id=211 CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Copyright and any other intellectual property rights in its contents are the sole property of Developmentor. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Flory Sent: 14 September 2005 12:53 To: [email protected] Subject: Re: [ADVANCED-DOTNET] Business logic I wouldn't necessarily call database languages primitive. They are a specialized tool for set based logic. Set based logic is something few developers understand. How much extra unindexed data will you bring over to the middle tier for processing? Also as far as change control goes it is easier to make a backend change than any other tier. Some one else made a comment about the database not scaling very well. Most of the poor performing databases I have seen were developer designed. No clustered index (heap tables), no other supporting indexes, no RI, cursors used instead of set based logic, multi-value fields, select * from, returning scalar values repeated in recordsets and so on. I am also pretty sure that 99% or more of the applications being written out there won't even come close to using up database resources, even many of the poorly written ones. So just because the only tool you can use is a hammer, that doesn't mean you should be using it on screws.... (BTW I am not advocating putting all the BL in the database or middle tier) Tim Flory Sr Programmer Analyst Phone: 216.464.2244 ext. 229 www.medquist.com This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. If you are not the intended recipient of this e-mail, promptly delete it and all attachments. "Unmoderated discussion of advanced .NET topics." <[email protected]> wrote on 09/13/2005 01:30:21 PM: > It depends highly on where those making the decisions are coming from. > Programmers tend to favor n-teir approaches where tasks are divided into > buckets that preform their assigned role. DBAs tend to push as much as > possible into the database engine letting the rest of the app to handle the > interface. > > I am a programmer - thus I tend to find the idea of keeping business logic > in the primitive database languages available abhorrant. I like to keep the > ability to completely ripout the business logic if necessary have have it > affect the other parts as little as possible. > > =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
