Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I have no experience with schema less DB combined with OOP, with I have year of experience with a schema less DB and scripting. From my experience, it can be quite usefull. The DB I've used was also untyped (all arbitrary strings). This leads to the following advantages:</p> <ul> <li>you don't have to take care about your DB structure. If you need to store something, you just store it. And you don't have to care about the data types which fits the scripting language</li> <li>you can easily add debug information to "objects" when needed without having empty columns for most of the table rows. This allows you to even store huge chunks of data where needed,</li> <li>you don't have to care about updates to the DB structure. You just write the new data which comes with your new software version to the database. This way, you don't need an admin to update your table structure and convert your old data. It just happens on the fly</li> <li>if the key for your key-values pairs has a meaningfull name, you don't need much documentation for your data</li> </ul> <p>So in my case, the schema less DB together with the scripting was very usefull and a huge success.</p> <p>When you think of using objects for the schema less DB, I would try to keep the freedom by storing the objects in a hashtable. This would give you the freedom to access all the key-value pairs - no matter which "object" you selected. It would also give you the freedom to add new key-values as needed.</p> <p>If your objects (like in an RSS feed) have a well defined base, it makes sense to come up with a base objects which encapsulates the well defined base but also has some kind of hash map for your freedom.</p> <p>As soon as you discover that more and more key-value pairs turn out to be "standard", just update your object model to encapsulate these - you software will evolve into the right data structure. May it makes even sense to move some of the data to a traditional RMDBS at a later time.</p> <p>Don't over engineer - implement the features when needed...</p>
    singulars
    1. This table or related slice is empty.
    1. POBest practices to access schema-less data?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USrdmueller
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

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