What do you get
	SQL Server database
		Each table has an audit/history table behind it. All changes to a record in the former is saved to the latter automatically by the triggers in the former. The latter is ready for the ODS of a data warehouse. Each many-to-many relationship table gets a view that displays linked records from both sides of the relationship. Each table gets a stored procedure for insert, update, search and status change. A base table (as opposed to a junction table) gets two delete stored procedures, one for "hard" delete (physical removal of a record) and one for "soft" or "logical" delete (the status of the record is changed to "Deleted"). A junction table gets two pairs of delete stored procedures: one pair by the primary key, and the other by the unique key. Each table also gets a number of list stored procedures, which tend to return a recordset, and a number of select stored procedures, which return one record for each ID/key. For example, the Account table (for accounting) gets the following stored procedures: spAccountDeleteL ("L" stands for "Logical delete".) spAccountDeleteP ("P" stands for "Physical delete".) spAccountInsert (Insert) spAccountUpdate (Update) spAccountFind (Search) spAccountSetStatus (Status change) spAccountListByActionProcesIdsUpdateDate (ActionProcesId is a foreign key in the table.) spAccountListByActionProcesIdUpdateDate (ActionProcesId is a foreign key in the table.) spAccountListByMmBdgtitemId (There is a many-to-many relationship between the Account and Bdgtitem (budget item) tables. "Mm" stands for "Many-to-many".) spAccountListByMmBdgtitemIds (There is a many-to-many relationship between the Account and Bdgtitem (budget item) tables. "Mm" stands for "Many-to-many".) spAccountListByMmLeftId (There is a self many-to-many relationship between the accounts in the Account table, stored in the AccountRelation table. "Mm" stands for "Many-to-many".) spAccountListByMmLeftIds (There is a self many-to-many relationship between the accounts in the Account table, stored in the AccountRelation table. "Mm" stands for "Many-to-many".) spAccountListByMmRightId (There is a self many-to-many relationship between the accounts in the Account table, stored in the AccountRelation table. "Mm" stands for "Many-to-many".) spAccountListByMmRightIds (There is a self many-to-many relationship between the accounts in the Account table, stored in the AccountRelation table. "Mm" stands for "Many-to-many".) spAccountListByMmOrgId (There is a many-to-many relationship between the Account and Org tables, stored in the AccountOrg table. "Mm" stands for "Many-to-many".) spAccountListByMmOrgIds (There is a many-to-many relationship between the Account and Org tables, stored in the AccountOrg table. "Mm" stands for "Many-to-many".) spAccountListByMmTypeId (There is a many-to-many relationship between the Account and Type tables, stored in the AccountType table. "Mm" stands for "Many-to-many".) spAccountListByMmTypeIds (There is a many-to-many relationship between the Account and Type tables, stored in the AccountType table. "Mm" stands for "Many-to-many".) spAccountListByStatus (StatusTypeId is a foreign key in the table.) spAccountListByStatuses (StatusTypeId is a foreign key in the table.) spAccountSelectById (A query by the primary key ID) spAccountSelectByIds (A query by the primary key IDs) spAccountSelectByMmIds ("Mm" stands for "Many-to-many". This is a query using IDs from any of the many-to-many relationships (combined or not) linked to the account table.) spAccountSelectIdByUk ("Uk" stands for "Unique key") Another example is the AccountOrg table (the many-to-many relationship table between the Account and Org tables), which gets the following stored procedures: spAccountOrgDeleteByPkL ("Pk" stands for "Primary key", and "L" for "Logical delete".) spAccountOrgDeleteByPkP ("Pk" stands for "Primary key", and "P" for "Physical delete".) spAccountOrgDeleteByUkL ("Uk" stands for "Unique key", and "L" for "Logical delete".) spAccountOrgDeleteByUkP ("Uk" stands for "Unique key", and "P" for "Physical delete".) spAccountOrgInsert (Insert) spAccountOrgUpdate (Update) spAccountOrgUpdateKeyColumnsByPk ("Pk" stands for "Primary key".) spAccountOrgUpdateKeyColumnsByUk ("Uk" stands for "Unique key".) spAccountOrgUpdateNonKeyColumnsByPk ("Pk" stands for "Primary key".) spAccountOrgUpdateNonKeyColumnsByUk ("Uk" stands for "Unique key".) spAccountOrgFind (Search) spAccountOrgSetStatusByPk ("Pk" stands for "Primary key".) spAccountOrgSetStatusByUk ("Uk" stands for "Unique key".) spAccountOrgListByLeftId (A query by AccountId) spAccountOrgListByLeftIds (A query by AccountIds) spAccountOrgListByRightId (A query by OrgId) spAccountOrgListByRightIds (A query by OrgIds) spAccountOrgListByMmLeftId (There is a self many-to-many relationship between the records in the AccountOrg table, stored in the AccountorgRelation table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmLeftIds (There is a self many-to-many relationship between the records in the AccountOrg table, stored in the AccountorgRelation table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmRightId (There is a self many-to-many relationship between the records in the AccountOrg table, stored in the AccountorgRelation table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmRightIds (There is a self many-to-many relationship between the records in the AccountOrg table, stored in the AccountorgRelation table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmPeriodId (There is a many-to-many relationship between the AccountOrg and Period tables, stored in the AccountorgPeriod table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmPeriodIds (There is a many-to-many relationship between the AccountOrg and Period tables, stored in the AccountorgPeriod table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmTranscnId (There is a many-to-many relationship between the Transcn and AccountOrg tables, stored in the TranscnAccountorg table. "Mm" stands for "Many-to-many".) spAccountOrgListByMmTranscnIds (There is a many-to-many relationship between the Transcn and AccountOrg tables, stored in the TranscnAccountorg table. "Mm" stands for "Many-to-many".) spAccountOrgListByStatus (StatusTypeId is a foreign key in the table.) spAccountOrgListByStatuses (StatusTypeId is a foreign key in the table.) spAccountOrgSelectByMmIds ("Mm" stands for "Many-to-many". This is a query using IDs from any of the many-to-many relationships (combined or not) linked to the AccountOrg table.) spAccountOrgSelectByPk ("Pk" stands for "Primary key".) spAccountOrgSelectByPks ("Pks" stands for "Primary keys".) spAccountOrgSelectByUk ("Uk" stands for "Unique key".) spAccountOrgSelectByUks ("Uks" stands for "Unique keys".) spAccountOrgSelectIdByUk ("Uk" stands for "Unique key".) Please note that the following stored procedures are left out for the junction table to reduce the number of total stored procedures: spAccountOrgListByRelationTypeId spAccountOrgListByRelationTypeIds These and other stored procedures can be easily added if required. Others can be easily excluded if not needed, such as the following: spAccountOrgUpdateKeyColumnsByPk (Update) spAccountOrgUpdateKeyColumnsByUk (Update) spAccountOrgUpdateNonKeyColumnsByPk (Update) spAccountOrgUpdateNonKeyColumnsByUk (Update) Select statements spanning two or more relationships, which are useful for reports, are provided in a separate table. All these stored procedures are generated automatically from the metadata.
	Application tiers
		Each stored procedure gets a public method in the data service tier, which is called by a public method in the business middle tier, which is called by a private method in the web presentation tier. The application tiers are generated automatically from the metadata. Each application comes with five administrative wizards automatically at stage I (more could built at stage II): (1) The Type Group wizard for type group management. (2) The Type Filter wizard for defining types that will appear in a dropdown box. (3) The Record Anvil wizard for adding and editing a record in any table. (4) The Role Access wizard for the management of role access. (5) The Role Members wizard for the management of role members.
	Wizard
		A wizard is provided for each business rule. A wizard is developed in 7 steps: (1) Documentation. (2) Development of a test SQL stored procedure according to the document. (3) Metadata entry. (4) If an all-steps-in-one page is required, automatic creation of it from the metadata. (5) If an all-steps-in-one page is required, manual code adjustment of the page. (This is a separate step from 4 above). (6) Testing with the test SQL stored procedure. (7) User acceptance test.
		Therefore, for each wizard, you get a document, a test stored procedure, the metadata in the database, and an all-steps-in-one page if it is required.

Home	|	Company	|	Privacy	|	Disclaimer
© 2009, 2015 XQ Knowledge Management