Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Writing Nearly Codeless Apps: Part 2 Expand / Collapse
Author
Message
Posted Tuesday, October 12, 2010 9:23 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Comments posted to this topic are about the item Writing Nearly Codeless Apps: Part 2
Post #1003338
Posted Wednesday, October 13, 2010 5:35 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 6:53 AM
Points: 13,890, Visits: 28,285
Oh please no, not tables named TBxxx. That's just so 1992 (not to mention, very, very Access). Surely, at this point in history, we can simply name a table, or an object in code, for the business need it represents. The whole concept of Hungarian style notation should surely be dieing in this day & age.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1003489
Posted Wednesday, October 13, 2010 6:22 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Grant Fritchey (10/13/2010)
Oh please no, not tables named TBxxx. That's just so 1992 (not to mention, very, very Access). Surely, at this point in history, we can simply name a table, or an object in code, for the business need it represents. The whole concept of Hungarian style notation should surely be dieing in this day & age.

Unfortunately in this day & age we still don't have relational databases that allow us to divide our various objects into different name spaces, so this task is left to the developer. At some point we are potentially going to want to name one thing "table X" and another thing "view X", and the only difference in the names will be whatever we choose to designate something as being a "view" vs. "table". If we choose nothing to designate tables from views, then we have to start making arbitrary name choices in order to accomplish this, but the whole point of RAP is consistency, and its code generators never make arbitrary choices.

With regards to the "xxx": this is no different that putting things into .NET name spaces. Once again, the relational database does not give us any tools for compartmentalizing our tables, so we must unfortunately do it ourselves. Presumably if we object to this convention (or at least some convention for accomplishing this) then we'd also prefer the good old days of VB6, where every global object was in the same gigantic name pool.

The design decisions of RAP were not made with regards to what was or is in or out of fashion. Rather they were designed to give RAP maximum capability for managing database object names with a maximum of regularity and a minimum of arbitrary variation.
Post #1003517
Posted Wednesday, October 13, 2010 6:49 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 6:53 AM
Points: 13,890, Visits: 28,285
I'm OK with the xxx part. Sorry that was just meant to designate '*' or 'whatever' or 'fillintheblank.' My only exception was with the Hungarian notation on table names.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1003550
Posted Wednesday, October 13, 2010 7:13 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, December 2, 2013 6:30 AM
Points: 346, Visits: 691
Ok, I have a problem with the approach from the word go, and it's this:

"implement "ideal" auditing, where the app itself can recall all versions of the data that were ever entered into it;"

*All* versions? :)

You do realize this is physically impossible, yes? The storage requirements for a CRM system are already astronomical, and that's just for the *current* state of the data. Add in a requirement that you keep EVERY SINGLE CHANGE (presumably reversibly) and you've moved from engineering to magic.

Given that, the rest of the approach is seriously suspect.

Unless, of course, I misunderstood "all versions of data ever entered"...

Post #1003585
Posted Wednesday, October 13, 2010 7:46 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
roger.plowman (10/13/2010)
Ok, I have a problem with the approach from the word go, and it's this:

"implement "ideal" auditing, where the app itself can recall all versions of the data that were ever entered into it;"

*All* versions? :)

You do realize this is physically impossible, yes? The storage requirements for a CRM system are already astronomical, and that's just for the *current* state of the data. Add in a requirement that you keep EVERY SINGLE CHANGE (presumably reversibly) and you've moved from engineering to magic.

Given that, the rest of the approach is seriously suspect.

Unless, of course, I misunderstood "all versions of data ever entered"...



RAP is intended for use primarily by small to medium projects, so given today's enormous storage capacities, storing all versions of every record ever deleted isn't really that big of an issue. But aside from that, RAP uses two distinct sets of tables: the primary or "current" tables holding current data, and the "archive" (or "audit" or "shadow" tables) in which all past versions of records are stored. At some point a large project could decide that all data beyond a particular date is forever obsolete, and it could simply delete that data from the archive tables. So even for a large project, RAP could easily handle the space-constraint problem because it neatly segregates its past data for you. And since RAP keeps only current data in its "current" tables, your app never has to wade through past data to find current data.

I have worked on several large projects where the project is informally storing every version of every record ever entered in many of its tables, but it's always done badly. Every one of these projects has accomplished this by using "effective date" fields or "deleted" flags. These mechanisms are horrendous because 1) every query that looks into any table has to account for the fact that there are possibly multiple versions of every record and it has to find the latest (or valid) one, 2) the presence of such data requires that keys and indexes accommodate this "archiving" (rather than representing the natural current structure of the problem) and 3) of course the performance is a disaster because in addition to every query having to do the extra query work described in "1" above, the vast majority of data in the tables is obsolete, yet the server must look through it on every single query for current data (which is 99% of the queries).

RAP eliminates the arbitrary nature of deciding which tables get audited and which don't. It eliminates the need for developers to design specialized auditing mechanisms (both storage and retrieval) because it implements both the storage and retrieval mechanisms for you automatically. It separates current from past data, making it both easy and efficient to either keep or dispose of the past data as you wish.

So please, stick with the series and give this a chance. It is really well thought out. I don't think I've missed a trick here, and at the end I'm hoping you'll agree.
Post #1003614
Posted Wednesday, October 13, 2010 7:57 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 13, 2011 7:07 AM
Points: 3, Visits: 49
I agree with many of your comments, especially on naming conventions. Naming conventions are totally arbitrary and are meant to allow the team to work together with minimal communication issues. I am consultant and each project we get the team to agree to naming standards before we start. They are necessary and what works for the team is acceptable.

And now the big BUT , after over 40 years of development I have learned you do not name data elements based on their attributes ... never. I am referring to your DR, DT notations. How much effort is required to change the application if a column is changed from a nullable to not nullable or the other way around? Where are all the column references? How about the references outside RAD like reporting and BI applications and their meta-data? I am not saying you can't manage this, but why introduce the risk?

Overall, good job and good ideas. Many low cost UML tools implement this philosophy and provide for standard name generation, key structures, DOM, etc. and they have the ability to support multiple DBMSes and application environments (i.e. .net vs java, IIS vs others, etc).
Post #1003627
Posted Wednesday, October 13, 2010 8:03 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 13, 2011 7:07 AM
Points: 3, Visits: 49
The auditing is a requirement for many systems today. Can you say SOX or HIPAA? Disk is cheap, this is one of the major strengths of concept.
Post #1003638
Posted Wednesday, October 13, 2010 8:20 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 10:16 AM
Points: 2,331, Visits: 566
David Ziffer (10/13/2010)
With regards to the "xxx": this is no different that putting things into .NET name spaces. Once again, the relational database does not give us any tools for compartmentalizing our tables, so we must unfortunately do it ourselves.

Ever heard of schemas?

MSDN: http://msdn.microsoft.com/en-us/library/ms365789.aspx
A schema is a container that holds tables, views, procedures, and so on. … Every securable in a specific schema must have a unique name. The fully-specified name of a securable contained by a schema includes the name of the schema that contains it. Thus, a schema is also a namespace.



David Ziffer (10/13/2010)
At some point we are potentially going to want to name one thing "table X" and another thing "view X", and the only difference in the names will be whatever we choose to designate something as being a "view" vs. "table".

If that's the case then your database design sucks. If there's a table called "Customers", why would there ever be a view called "Customers" in the same schema? It's pointless and confusing.



Post #1003665
Posted Wednesday, October 13, 2010 8:49 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, September 8, 2014 8:18 AM
Points: 26, Visits: 265
First of all, I applaud you for sharing your theory (and effort) related to design standardization such that it will permit automated code generation. I am also developing a custom framework because I do not believe the existing models and tools go far enough in some areas and because of some custom requirements in our business model. I guess that means I am re-inventing the wheel on a massive scale but the ROI is there for us.

For object (table, view, proc, etc) naming conventions you might consider using schemas instead of Hungarian notation. I realize not all RDBMSs support schemas equally but we sure take advantage of them in our SQL2008 environment.

I look forward to reading your future posts in this regard.
Post #1003703
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse