Federate Your Data for Internal and Limited External Consumption

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 3^rd 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)