Writing Nearly Codeless Apps: Part 3

Question

Post reply

Writing Nearly Codeless Apps: Part 3

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply

David Ziffer SSCommitted Points: 1513 More actions · Answer 1

Pantelis Magos (10/21/2010)
Where are the links for Parts 1 and 2?

Just do a search (using SQL Server Central's Search box) on the article title.

bjl2 Grasshopper Points: 14 More actions · Answer 2

I enjoyed your articles, and I look forward to the rest of them, and to trying out the framework you discuss.

I'm neither a DBA, nor a Developer (yet); I work in QA, so please excuse any ignorance on my part. This method of development is fantastic, from a QA perspective, but would it not be a performance nightmare for many applications?

The first article said "The objective here is to produce small to medium database-based applications". The application I work with daily is certainly no Amazon.com. It is a client-server app with around 1200 tables, but most of them are small. A few of them may reach a couple of million records, though. Does that put it outside the scope of the methodology proposed in the article?

Performance, especially of long-running processes, is a constant issue for our largest customers, and we continually have to talk even large, well-funded organizations into upgrading their servers.

I would much appreciate some discussion of performance implications in the future articles of this series.

Thank you,

Ben Langton

charles-600573 Grasshopper Points: 17 More actions · Answer 3

I am not sure I am missing something here.

You state:

"This example tracks the progress of auditing in just one table. All the tables in the database, without exception, operate on this same principle"

mmm.

Surely if you delete a record from the AdmUser Table (hopefully the constraint won't let you), it would mess up.

Cheers

David Ziffer SSCommitted Points: 1513 More actions · Answer 4

charles-600573 (10/26/2010)
I am not sure I am missing something here.
You state:
"This example tracks the progress of auditing in just one table. All the tables in the database, without exception, operate on this same principle"
mmm.
Surely if you delete a record from the AdmUser Table (hopefully the constraint won't let you), it would mess up.
Cheers

Certainly you can put business rules in your app that prevent you from deleting things that should not be deleted. But that is (properly) up to the business rules, not the database.