Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'll just call out one or two common reasons (I'm sure people will be writing essay answers)</p> <ol> <li><p>With highly distributed systems, any given data set may be spread across multiple servers. When that happens, the relational constraints which the DB engine can guarantee are greatly reduced. <em>Some</em> of your referential integrity will need to be handled in application code. When doing so, you will quickly discover several pain points:</p> <ul> <li>your logic is spread across multiple layers (app and db)</li> <li>your logic is spread across multiple languages (SQL and your app language of choice)</li> </ul> <p>The outcome is that the logic is less encapsulated, less portable, and MUCH more expensive to change. Many devs find themselves writing more logic in app code and less in the database. Taken to the extreme, the database schema becomes irrelevant. </p></li> <li><p>Schema management—especially on systems where downtime is not an option—is difficult. reducing the schema complexity reduces that difficulty.</p></li> <li><p>ACID doesn't work very well for distributed systems (<a href="http://queue.acm.org/detail.cfm?id=1394128" rel="noreferrer">BASE</a>, <a href="http://en.wikipedia.org/wiki/CAP_theorem" rel="noreferrer">CAP</a>, etc). The SQL language (and the entire relational model to a certain extent) is optimized for a transactional ACID world. So some of the SQL language features and best practices are useless while others are actually harmful. Some developers feel uncomfortable about "against the grain" and prefer to drop SQL entirely in favor of a language which was designed from the ground up for their requirements.</p></li> <li><p>Cost: most RDBMS systems aren't free. The leaders in scaling (Oracle, Sybase, SQL Server) are all commercial products. When dealing with large ("web scale") systems, database licensing costs can meet or exceed the hardware costs! The costs are high enough to change the normal build/buy considerations drastically towards building a custom solution on top of an OSS offering (all the significant NOSQL offerings are OSS)</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POWhat's the attraction of schemaless database systems?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAndrew Marshall
    1. USAddys
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat's the attraction of schemaless database systems?
      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. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI do not think cost should be one of the considerations for not going with a RDBMS vs NOSQL solution. There are plenty of free Open source RDBMS'es out there such as MySQL and Postgres that can scale well enough.
      singulars
      1. PO
      1. USDeep Kapadia
    2. CO"Well enough" is extremely relative. Each system has a different set of considerations, and cost is often one of them. If not the direct cost of licensing then at least the indirect costs such as tools, market rates for experienced developers on your stack, etc.
      singulars
      1. PO
      1. USAddys
    3. CO@Deep Kapadia has a valid point since you mentioned licensing cost and no other costs in #4. MySQL and PostgreSQL do scale well. The rest of the answer contains really great points, imho #4 doesn't really belong in your answer.
      singulars
      1. PO
      1. USjgauffin
 

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