Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'll stand up in 2 roles here</p> <ul> <li>DBA: Database admin/designer.</li> <li>Dev: Application developer.</li> </ul> <p>I assume the DBA is a person who <strong>really</strong> know all the Database tricks. Reaallyy Knows.</p> <hr> <p><strong>DBA:</strong><br> <strong>Database is the key</strong> of the application and should have predefined structure in order to serve its purpose well and with best performance.<br> If you cannot use random schema (which is reasonably normalised and good) then the tools are wrong.</p> <p><strong>Dev:</strong><br> The <strong>database is just a data store</strong>, so we need to keep it simple and concentrate on the application.</p> <p><strong>DBA:</strong><br> Database is not a store it is the core of the application. There is no application without database.</p> <p><strong>Dev:</strong><br> No. The application is the core. There is no application without the front-end and the business logic applied to it. </p> <p><em>And the war begins...</em></p> <hr> <p>Both points are valid and it is always trade off. </p> <p>If the database will ONLY be used by RoR, then you can use it more like a <strong>simple store</strong>.<br> If the DB can be used by <strong>other application</strong> OR it will be used <strong>with large amount of data</strong> and <strong>high traffic</strong> it <strong>must enforce some best practices</strong>. </p> <p>Generally there is no way you can disagree with DBA.<br> But they can understand your situation and might allow you to loose the standards a bit so you could be more productive. </p> <p>So you need to <strong>work closely, together</strong>. </p> <p>And you need to <strong>talk to each other to explain and prove the point</strong> why database should be like <em>this</em> or <em>that</em>.<br> Otherwise, the team is broken and project can be failure with hight probability.</p> <hr> <p>ActiveRecord is a very handy tool. But it cannot do everything for you. It does not provide Database structure by default that you expect exactly. So it should be tuned. </p> <p>On the other side. If DBA can accept that all PKs are Auto incremented integers that would make Developer's life easier (ActiveRecord does it by default). </p> <p>On the other side, if developers would accept some of DBA constraints it would make DBA's life easier.</p> <hr> <p>Now to answer your question:</p> <blockquote> <p>how would you argue FOR simplifying the schema</p> </blockquote> <p>Do not <em>argue</em>. Meet the team and deliver the message and point on WHY it should be done.<br> Maybe it really shouldn't and you don't know all the things, maybe they are not aware of something. </p> <p>You could agree on the general structure of the database AND try to describe it using RoR migrations as a meta language.</p> <p>This way they would see the general picture, and you would use your great ActiveRecords. And also everybody would be on the same page.</p>
    singulars
    1. This table or related slice is empty.
    1. POThe Ruby community values simplicity...what's your argument for simplifying a db schema in a new project?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDmytrii Nagirniak
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POThe Ruby community values simplicity...what's your argument for simplifying a db schema in a new project?
      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. VTAcceptedByOriginator
    1. COVery well put, Dmitriy. I especially like your zen attitude toward 'arguing'
      singulars
      1. PO
      1. USbtelles
 

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