Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>My best guess is that a table like this is used to store arbitrary data (inferred from the other supporting tables) that won't require schema changes to store information that is "unplanned" or not yet implemented in the business logic of the application.</p> <p>The questions I would start asking (yourself, any programmers, DBA's, project managers, etc.):</p> <ul> <li>Were the requirements so abstract at the time that it was impossible to create a formal schema with data relationships? (Bad, bad, BAD)</li> <li>Was the database designer lazy or inexperienced?</li> <li>Was the programmer lazy or inexperienced? (Better yet, was the programmer the DBA?)</li> <li>Is the reliability/availability of the data so sensitive that making formal schema changes is hard to do on a regular basis?</li> <li>Has the project gone through plenty of people before you that simply inherited the problems, and this is a hack solution? (While maybe the original programmer knew where it was intended to go eventually...)</li> </ul> <p>I think what you're really trying to get at here is "does this work, or should I change it?". I'd be shocked if the any read/search queries are optimized at all, as there couldn't be any indexes for such arbitrary data storage. If the application is simply logging information, it probably isn't as big of a deal, as the originator probably just didn't know yet how the data would be used later on, and writing a one-time applet to loop through and create formal objects out of the data would be better than trying to assume everything at the beginning.</p> <p>Getting a little more targeted, are you running into any bottlenecks in your process because of this particular table, or are you concerned just out of surprise? If the former, I'd figure out how to change it right away. If the latter, I'd take my time figuring out the long-term requirements of the application first.</p>
    singulars
    1. This table or related slice is empty.
    1. POSQL Server Normalisation/Best Practices: Single Data Table
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USlandons
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSQL Server Normalisation/Best Practices: Single Data Table
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThe database was developed without any knowledge of our IT department, and hence why I am now inheriting the application. Delving into the logic of the database, it appears several Access forms with different sets of fields are hooking into this one table.
      singulars
      1. PO
      1. USMustering
    2. COThe DB was designed without any IT knowledge, which is required here. I assume the guy went on an short Access/VBA course and considered himself "an expert". Basically, it is a data-entry logging application recording different types of data for the finance dept.
      singulars
      1. PO
      1. USMustering
    3. COEach form a dfferent set of unbound up to 100 control fields and one "maintenance" screen to link these controls to the record and field back to the database. My concern is the long term viability and performance with 893,135 records to be precise. I have to now support it, and the question was asked if redevelopment was an option. My question is: Is this single 'compact' structure good for data entry/retrieval and what purpose does it achieve? Each record would need to return 100+ records instead of 1 record from a strucured table. However, will one long 100+ have performance issues?
      singulars
      1. PO
      1. USMustering
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload