Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>I'm not sure where to start. </p> </blockquote> <p>We always start with the data model.</p> <blockquote> <p>having never worked with databases before, how to I incorporate these items into the models and test units?</p> </blockquote> <p>Ah, well, there's the problem.</p> <p>You have to start with the data, because everything starts with the data.</p> <ol> <li><p>Write use cases. Your 5 technical requirements aren't really very good use cases because there's no Actor who interacts with a system. You need to write down the things an actor does -- what the actor interacts with.</p></li> <li><p>Identify the objects that the actor interacts with. When in doubt, write down all the nouns in your use cases.</p></li> <li><p>Draw a picture of the classes that will implement those objects.</p></li> <li><p>Walk through your use cases to be sure that all the things an Actor needs to do are based on attributes of your class definitions. All the data an actor needs has to be in these classes, which will become tables in your database.</p></li> </ol> <p>Now, you have to start doing more technical work. You need a web framework with an ORM layer. You're using PHP, so you'll have to find a good framework for this. Cake or Doctrine or something.</p> <ol> <li><p>Define one class in your ORM layer. You don't have to be complete or precise, you just need something that you can test with.</p></li> <li><p>Write unit tests for this class to be sure that it has the right data elements. This will be relatively simple at first, since your individual data classes will start out simple.</p></li> </ol> <p>Once the basic set of classes are defined, you'll need to look at relationships among classes. This is where the real work starts.</p> <ol> <li><p>Look at a relationship in your picture. Any line. Pick one randomly.</p></li> <li><p>Write unit tests to be sure that you can "navigate" across that line. From one object, fetch the related objects at the other end of the line. This shouldn't be very complex, just a few lines of code. </p></li> <li><p>Create a "fixture" -- test data you can load into a database -- to represent the objects and their relationships.</p></li> <li><p>Run the test. If it breaks, update your ORM definitions to support the navigation properly.</p></li> </ol> <p>When you've finished doing all the various relationships, you will have built a reasonable complete data model in a Test-Driven manner.</p> <p>Now you can build your PHP presentation for the model objects. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhere to start with the development of first database driven Web App (long question)?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USS.Lott
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhere to start with the development of first database driven Web App (long question)?
      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 don't generally like to start with the data model - I think it leads you to an anemic domain model - but you lay out a pretty good design session.
      singulars
      1. PO
      1. USMark Brackett
    2. CO@Mark Brackett: "anemic"? How can you start with anything else? If you start with GUI presentation, your data model becomes a confusing hash based on one particular presentation and any small change to that presentation breaks the model. The data model is foundational to everything. What can you possibly mean by "anemic"?
      singulars
      1. PO
      1. USS.Lott
    3. CO@S.Lott - Personally, I find that UI or domain first is better for fleshing out behavior. Data first, IME, leads to a "domain" model that's little more than getters/setters - often with unneeded and complex relationships between them. When forced to add behavior - it tends to go into services, controllers, or stored procs.
      singulars
      1. PO
      1. USMark Brackett
 

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