Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Properly Getting Into Jail: Counting Inmates and Other Hard Problems

DZone's Guide to

Properly Getting Into Jail: Counting Inmates and Other Hard Problems

We relate the way a database works to the way counting inmates of a prison works. After all, the secret to a successful prison is keeping the people there inside.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

In prison, the notion of counting people is sacred. This is probably because the whole point of having a prison is to keep the people you put in there inside, and that means that you count inmates multiple times a day.

The dirty secret, however, is that you almost never get to that perfect occupancy number, where all the inmates that are registered to a particular block are actually in that block. In most cases, you have at least a few that are outside the block (court dates, medical issues with offsite care, visitations, outside work, etc.).

So the key here is not just to count the inmates, but to also account for them. Let’s consider how this will look like in the user interface for counting a couple of cells, shall we?

Snapshot

This works, but it isn’t a good idea. Named counts are usually reserved for the first and last counts of the day. During the day, because it is so frequent to have inmates in and out of their assigned location, you’ll usually do things differently. You’ll have a total count of inmates in the block, and a list of the exceptions. That would look something like this:

Snapshot

You have the number of inmates in the block, how many are expected to be there, the actual count as verified by the sergeant’s signature, and the named list of inmates that are not currently in the block. You might have noticed that we are carefully tracking who is responsible for any inmate that is currently out of the block. This is because that matters (for a whole host of legal and cover your ass reasons).

So how would we build such a system?

To start with, we need to talk about the current component or service that we are building. The notion of counting is typically done at the block level, so we’ll start by modeling things there. We’ll have the Block Service, which is in charge of managing anything that is going on inside the block.

A block is composed of:

  • Cells to which inmates are assigned. This is typically an internal division only that has no real business meaning.
  • Inmates, which are quite important.
  • Staff, which is probably a separate issue entirely but is quite important for thing such as having enough people on hand to do things like actually run the block.

In terms of the actual operations we need to do, the block is managed by at least a single Sargent per shift and multiple guards. The Sargent is responsible for handling incoming inmates, counting all inmates multiple times a day and other things that we won’t be tracking on a computer system. The guards will mostly interact with the system when they need to check an inmate out for whatever reason (such as taking them to a checkup by a nurse).

With all of this information, we can now model the data we have for a block. Here is the most important document we have, the block’s population. There are a few things here that are worth exploring in the design of the document:

image

First, we have a separate document per date, recording the state of the block’s population at that time. This is important because we need to be able to go back in time and track such things. You can also see that the document contains a lot of data that has both the name and ID. Why is that?

The information recorded in this document is the data as it was at the time of this document’s creation. Later changes do not apply, by design, since we need to see keep it in the state it was at the time. It might be easier to look at things in code:

public class Inmate
{
	public string Id { get; set; } 
	public string Name { get; set; } 
}

public class Staff
{
	public string Id { get; set; } 
	public string Name { get; set; } 
}

public class InmateLogEntry
{
	public Inmate Inmate { get;set; }
	public Staff ResponsibleParty { get;set; }
	public LogStatus Status { get;set; } // checkin / checkout
	public string Notes { get;set; }
}

public class Block
{
	public List<InmateLogEntry> Log { get; set; }
	public List<Inmates> Inmates { get; set; } 
	public Staff Sargent { get; set; } 
}

The most important thing here is the notion of the Log, which records every incoming and outgoing inmate from the block.

In addition to the daily’s block population document, we also have three to five counting documents, which are built on top of it. These reflect the actual counts made plus the listing of inmates that aren’t currently on the block and why.

And that is quite enough about the prison’s life. This gives us sufficient level of details that we can now work with. The next post will talk about how the physical architecture and data flow in the prison.

Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

Topics:
database ,data flow ,data analytics

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}