Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The exact meaning of <em>should</em> in natural language is also not clear cut. When you say "the wheel <em>should</em> fit in the row" - what does that mean exactly? It may mean the same as <em>must</em>, but then there is no point in a construct for it. Else, at what confidence do you need to be for this to be satisfied? What is the action in case the wheel does not fit?</p> <p>In the senses you referred to, there are some equivalents, though I do not know of language that use the word <em>should</em> for them:</p> <h2>Testing/assertion</h2> <p><code>ASSERT</code> is often a language directive, macro, or testing library function. In the sense that <code>ASSERT</code> corresponds to <em>must</em>, some languages and testing frameworks define macros for "warning assertions" which will spit a warning message if the check fails but not bail out or fail the test - that would correspond to <em>should</em>.</p> <h2>Exception handling</h2> <p>In some terms, you can consider exception thrown as analogues - if an exception is caught, the program can handle the case where something is not as it <em>should</em> be. But sometimes the exception describes the failure of something to be as it <em>must</em> be for the program to work, in which case the exception will not be caught or the handler will make the program fail gracefully. This is however not always the case - sometimes code is executed to test something that <em>may</em> be or perhaps is even <em>unlikely</em> to be, and an exception is caught expecting that it will usually be thrown.</p> <h2>Constraint logic</h2> <p>One common meaning of <em>must</em> and <em>should</em> in various formal natural language documents is in terms of constraints - <em>must</em> specifying a constraint that you always have to satisfy, and if you cannot then your state is incompatible, while <em>should</em> means that you will always satisfy the constraint <em>if it is possible</em> given the state and the constraints implied by <em>must</em>, but <em>if it is not possible</em> that is still valid. In informal constraint logic, this occurs when there are "external constraints" in the context - so verifying that the "solution" is satisfactory with respect to the "<em>should</em> constraints" may be possible only with knowledge of the context, and given the context you may also be able to satisfy different subsets of the "<em>should</em> constraints" but not at the same time. For that reason, some constraint logic specification languages (whether you call them "programming languages" depends on your definition) have the concepts of ordering of constraints - the first level of constraints corresponds to <em>must</em>, the next level corresponds to <em>should</em>, and a constraint has to be satisfied if possible given all constraints external to it (in previous levels), even if that conflicts with some constraints in the next levels which will then not be satisfied.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs there a SHOULD (or other modal verb) constructs in any programming languages?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTom Alsberg
    1. USTom Alsberg
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs there a SHOULD (or other modal verb) constructs in any programming languages?
      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. COVery nice answer, do you have any quotes or its purely yours?
      singulars
      1. PO
      1. USRobert Gould
    2. CONo ideas here are originally mine, other than the interpretation and poor explanation... Obviously the constraint logic part is based on bits I learned about the subject at various times - I did not invent it. No direct quotes - but if you're interested the web and books are full with resources.
      singulars
      1. PO
      1. USTom Alsberg
    3. CO+1: Constraint logic is a good one. I was thinking perhaps NULL in SQL to mean 'should have a value but it is currently missing', leading perhaps to COALESCE(), which is similar to TRY CATCH FINALLY. But NULL is contraversial relationally :)
      singulars
      1. PO
      1. USonedaywhen
 

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