Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <ol> <li><p>Security. You're not granting DB access to anyone but web server/app user.</p> <p>This is extra important when you have tons of users. You avoid the pain of user/role maintenance on DB side.</p></li> <li><p>DB load reduction. Web service can cache the data it retrieved from DB.</p></li> <li><p>Ability for fault tolerance - the service can switch between primary/DR data sources without having details of fail-over be implemented by service consumers.</p></li> <li><p>Scalability - the service can spread requests between several parallel data sources without having details of the resource picking be implemented by service consumers.</p></li> <li><p>Encapsulation. You can change underlying DB implementation without impacting service users.</p></li> <li><p>Data enrichment (this includes anything from client customization to localization to internalization). Basically any of these might be useful but any of them is a major load on database and often very hard to implement inside a DB.</p></li> <li><p>May or may not apply to you - certain architecture decisions are not DB acces friendly. E.g. Java Servers running on Unix have an easy access to a database, whereas a java client running on a Windows PC is not database aware nor do you possibly want it to be.</p></li> <li><p>Portability. Your clients may not all be on the same platform/architecture/language. Re-creating a good data access layer in each one of those is harder (since it must take into account such issues as above-mentioned failovers/etc...) than building a consumer layer for a web service.</p></li> <li><p>Performance tuning. Assuming the alternative is clients running their own queries (and not pre-canned stored procedures), you can be 100% sure that they will start using less than optimal queries. Also, if the web service bounds the set of allowable queries, it can help with your database tuning significantly. I must add that this logic is equally applicable to stored procedures, not unique to web services.</p></li> </ol> <p>A good list can also be found <a href="http://www.agiledata.org/essays/implementationStrategies.html" rel="noreferrer">on this page: 'Encapsulating Database Access: An Agile "Best" Practice'</a></p> <p>Just to be crystal clear - some of these issues may not be applicable to ALL situations. Some people don't care about portability. Some people don't need to worry about DB security. Some people don't need to worry about DB scalability. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhy should a developer use web services instead of direct connections to a db?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDVK
    1. USDVK
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy should a developer use web services instead of direct connections to a db?
      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. COSorry, disagree. 1. So you grant DB access to a group instead of a single principal - no difference. 2. Any app can cache data. The kind of data that can be cached across multiple users will usually be low volume data in any case. 3. FT should be handled by the database in any case. 4. This is not an out of the box feature, and has to be programmed. 5. Your data access layer should be doing the encapsulation. 6. Same thing. 7. Really? JDBC doesn't run in a client? 8. Good point, when it matters, which is rare. 9. query vs. SP was not part of the question.
      singulars
      1. PO
      1. USJohn Saunders
    2. CO1. Try managing that across 5000 users with hundrends of roles. Does not scale so well anymore. 2. Depends entirely on an app. Our current case has an instance of caching results of a query which in uber-optimized case takes 20 minutes to run and which we need to run 100s of times a day at least from different apps. 3. FT is handled on a bunch of levels. What do you mean "should be handled by a database"?
      singulars
      1. PO
      1. USDVK
    3. CO4. Of course it has to be programmed. But it can be programmed into the service once, or into a zillion client apps on various platforms with varying capabilities. There's a major difference. Never mind the issues of configuration management for load balancing. 5. Same reasoning. You don't need to re-implement DAL. Matter of fact, you can just think of the web service as a portable DAL to ease your mind. 7. We don't want every client opening DB connections. Is that such a big thing to ask for? Again, you're forgetting points 1-5.
      singulars
      1. PO
      1. USDVK
 

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