Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What usually happens is that you run multiple servers. It's generally <strong>very bad</strong> practice to edit the actual website immediately. What if you create a bug? You must certainly will, since nobody programs flawless. There's a paradigm called DTAP</p> <ol> <li>Development </li> <li>Test </li> <li>Acceptance</li> <li>Production</li> </ol> <p>You develop op your development server, there you can do anything you want. Just mess around and try around stuff until you think you've created a new version. Then upload it to the test server, where you only update a full new version of the website. You can test and see if everything work.</p> <p>When you have created and tested a new version, you can upload it to the acceptance server, where the customer can see if it for fills it's needs. And when that's done you can upload it to the development server.</p> <p>Obviously, I understand that in some projects this is a big overkill. So you might want to merge the testing and the development on one server. But what's most important of this is. <strong>Make sure development and production is divided</strong>. So changes you do, do not immediately reflect on the production server, so if you create bugs, it wont affect the website. </p> <p>Also, it doesn't even have to be different physical servers, it may also be just different websites on the same server like:</p> <ul> <li>dev.example.com </li> <li>test.example.com</li> <li>acceptance.example.com</li> <li>example.com</li> </ul> <p>Also make sure you work on different versions of your software. Don't publish just tiny bits. But every time make sure you work towards a new "version" of the website, containing new functionality every time you upload it. Make sure you have certain goals you want to work to like:</p> <p>Add forum to website, add blog to website, add chatbox to website. And only publish it to production when it's done completely. </p> <p>Also, if you work in these updates, it's very easy deploy. You just upload a complete website, instead of just ftp'ing different single php file.</p> <hr> <p>I think in your case it would be best to create a subdomain on your host. Then duplicate the database (you could make something to automate this) and site. That way you have the most up-to-date version. When you've created something, push it to the default site. </p>
    singulars
    1. This table or related slice is empty.
    1. POintroduction to setup test server
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTimo Willemsen
    1. USTimo Willemsen
    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
    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. COVery good answer.
      singulars
      1. PO
      1. USBraedenP
    2. CO@Timo: I completely agree with this methodology, however if it's a small enough site or there are no users, you can get away with modifying the live site -- if only for a while. In other words, for prototyping this may be overkill. I'm still giving you +1 though.
      singulars
      1. PO
      1. USChris Eberle
    3. COYes Chris, I absolutly agree with you. Actually, I think I might discourage using the full DTAP methodology for very small websites. It just creates complexity that's never been used. On my personal websites, there's no use for acceptance server, since I'm the one who does the functionality checks. But I think knowing what's the best in ideal situations makes it possible to make good decisions on what to do.
      singulars
      1. PO
      1. USTimo Willemsen
 

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