Click here to Skip to main content
Click here to Skip to main content

Federate Your Data for Internal and Limited External Consumption

, 24 Jan 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
Create peace and unity in your organization by separating data and coding responsibilites

Not Your Father's Elks Club

Knowledge is power.

For many companies or, better expressed, organizations (because you, elk reader*, may be involved with the SPLC, the SPCA, the ACLU, Sea Shepherd, PITA, or who knows who), said knowledge lies "hidden" (sometimes it really is) inside your database[s].

* I'm trying to be politically and literally correct here, in recognition of the fact that not all readers are deer; in fact, some of you might be moose or even chamois (I don't blindly accept the commonly held notion that chamois can't read).

Anyway, that data, which contains so much valuable information, is of no use to anybody if it's not accessible. There are all sorts of reasons and scenarios why getting at the data may be problematic (technical, legal, "political," ignorance, etc.).

Expose Yourself, But Leave Something to the Imagination

The RESTful approach to exposing data can be a great help to organizations that need to make their data available internally (within their organization) and often also, in at least a limited way, externally.

By exposing the data you want others to have/see, you can control exactly what you are presenting to them. This is similar to the legacy pattern/practice familiar to dataheads (er, database professionals) where they create "Views" (virtual datasets) that they then make public, while keeping private certain columns in particular tables based on specific users' "need to know" (e.g., the   Human (or Non-human) Resources Department may need to have access to salary information, whereas others don't (it could even be legally "actionable" if this data were exposed to inquiring minds who have no legitimate need for such)).

Perhaps the most straightforward way to use the RESTful paradigm to expose just the data you want to expose, and nothing more, is by using ASP.NET Web API.

By using this technology, you can provide your internal developers or trusted 3rd parties (vendors, vendees/customers, etc.) with a list of URIs to use ("using this URI will get you all the customers ordered by purchase total", "this one will give you all clients from a particular state," etc.)

By making your RESTful (custom) API be the one "point of contact" with your organization's data, and letting it be the "One version of the truth," you are helping to unify your organization's understanding of its own data while simultaneously separating the responsibilities among the "geeks" by segregating the organization's data providers (dataheads / DBAs, or whatever you want to call them) from the organization's data consumers (programmers/developers).

Segaration!? What's Segaration?!?

This approach or philosophy lets coders do what they do best, without having to "fuss" with database arcana, and it lets the dataheads do what they do best (write obscure but "performant" queries while keeping a wary eye on private data that might otherwise leak out if non-dataheads were to have direct access to it).

A programmer can simply ask his opposite number in the data department, "Can you provide me the SQL that will allow me to query the database for every person who has contacted our customer support department from a given state within a given time frame?"

In 15 minutes*, the data guardian (or whatever you prefer to call him/her/it) will send you the query in an email (or neatly typed onto a small piece of paper, rolled up tightly, inserted into a small metal tube, and attached to the foot of a passenger pigeon).

The developer uses that SQL in his concrete Repository class, and then informs his fellow devs, "Here is the URL to use from a REST client to retrieve a record for every person who has contacted our customer support department from a given state within a given time frame; use this address and port, appending three arguments on the end: State abbreviation, MinDate, and MaxDate)."

* (multiplied by some random number of orders of magnitude - sometimes you have to "grease the wheels" with a carton of Jolt or a pair of tickets to a Justin Bieber concert)

In a short period of time, this sort of interaction will become routine, allowing for smoother and quicker turnaround times for those instances when somebody somewhere needs data (as y'all know, it happens all the time).

In order to travel down this road, you will need at least one DB expert on your team, preferably at least one who is a SQL/query guru, and one who is more a database administrator type. The need for the latter is less pressing if you use an administration-friendly DBMS like MS SQL Server -- as opposed to a beast like "BEHEMOTH" (AKA Oracle), which might require (YMMV, of course, depending on the size and complexity of your data) multiple DBA types.

Not All Links Are Sausages

If interested in cogitating further on this, you might find a couple of articles helpful, one on creating an ASP.NET Web API app and one on incorporating MS SQL Server into the mix.

If you like this tip, spend a few moments meditating on why George Washington is more famous than Toussaint Louverture; if the conclusions you reach make you mad (either angry or insane), take a break from that and pet your cat and/or give him some warm milk or, better yet, cream. If you don't have a cat (what?!? No cat?!?!?), go to India and pet a Siberian Tiger (or go to Siberia and pet an Indian Tyger)

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

B. Clay Shannon
Publisher "Found in the Translation"
United States United States
I am the entire team at "Found in the Translation," which produces multilingual books (paperback and Kindle versions) such as "Don Quixote: In Spanish and English, Paragraph-by-Paragraph" among many others (English paired with not only Spanish, but also French and even Finnish). You can see all those books here: http://jsfiddle.net/clayshannon/pRgQL/75/
 
Personal web sites that I have created can be seen at http://usamaporama.azurewebsites.net and http://bigsurgarrapata.azurewebsites.net/
 
Peripatetic and picaresque, I have lived in eight states; specifically, besides my native California (where I was born and where I now again reside) in chronological order: New York, Montana, Alaska, Oklahoma, Wisconsin, Idaho, and Missouri.
 
I am also a writer of both fiction (for which I use a nom de plume, "Blackbird Crow Raven", as a nod to my Native American heritage - I am "½ Cowboy, ½ Indian") and nonfiction: http://www.lulu.com/spotlight/blackbirdcraven
Follow on   Twitter   Google+   LinkedIn

Comments and Discussions

 
GeneralYou're quirky. PinmemberKChandos30-Jan-14 11:53 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.141015.1 | Last Updated 24 Jan 2014
Article Copyright 2014 by B. Clay Shannon
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid