Click here to Skip to main content
12,824,787 members (39,365 online)
Click here to Skip to main content
Add your own
alternative version


3 bookmarked
Posted 24 Jan 2014

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)


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


About the Author

B. Clay Shannon
Founder Across Time & Space
United States United States
I am in the process of morphing from a software developer into a portrayer of Mark Twain. My monologue (or one-man play, entitled "The Adventures of Mark Twain: As Told By Himself" and set in 1896) features Twain giving an overview of his life up till then. The performance includes the relating of interesting experiences and humorous anecdotes from Twain's boyhood and youth, his time as a riverboat pilot, his wild and woolly adventures in the Territory of Nevada and California, and experiences as a writer and world traveler, including recollections of meetings with many of the famous and powerful of the 19th century - royalty, business magnates, fellow authors, as well as intimate glimpses into his home life (his parents, siblings, wife, and children).

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, including a two-volume social and cultural history of the U.S. which covers important events from 1620-2006:

You may also be interested in...


Comments and Discussions

GeneralYou're quirky. Pin
KChandos30-Jan-14 12:53
memberKChandos30-Jan-14 12:53 

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

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

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170308.1 | Last Updated 24 Jan 2014
Article Copyright 2014 by B. Clay Shannon
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid