Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
<pre> <div id="tableSchema"> There are seven tables to handle this application. The table structure here is fairly normalized and accomplishes the following tasks: • Makes data digestible (atomic - broken down to its simplest form) for accurate and powerful reporting operations. • Cuts down the number of tables to 1/3 by combining some 20 tables into two tables (tDefinition and tResponseSpecific). • Facilitates development of robust and user-friendly interfaces resulting in continuous savings for the life of the application. • Is ready to handshake with any additional tables required to perform some functionalities in the future. Table Descriptions: CDS-specific data is stored in four tables, tRequest (4), tPositionRequest (5), tResponse (6) , and tResponseSpecific (7). The remaining five tables handle the generic data that is already in use by the other Oracle based applications. For performance purpose, because this application uses less than 0.5% of the data in the existing Oracle tables, the following redundant tables are included with this application: Generic (utility) tables: 1. tPeople: This table keeps personal data such as name, address, phone, etc. regardless of what work they perform. Only first name, MI, and last name are entered to this table. The rest of the fields in this table are uploaded frequently based on some other well maintained tables. 2. tPosition: This table matches people’s function(s) throughout the system allowing a professional to be assume different hats at different groups. in one or more facilities. Allowing, for example, a doctor function at different capacities in different groups in one or more facilities. </div> </pre>
Join the community of 500,000 technology professionals and ask your questions.