Custom databases - doing anything you'd like, anywhere you need.

What kind of database do you need?

If you’re storing information for most classical business needs – such as AP, AR, inventory, manufacturing – and you picture the data as naturally falling into columns and rows - the column headers reading things like “part number” and “manufactured date” and rows being records of distinct parts –

Or a similar example: an invoice – with the rows being the record of part of the bill to the customer -

Then you should stay with a classical system, such as MYSQL, or Microsoft’s SQL Server, or Oracle ( but I recommend MYSQL as it’s free :>) ) These lend themselves to relational models – wherein for example, customers are in one table and the invoices are in another, and the two are linked with “customer number”.

Popular now in some places are “NOSQL” structures, like MongoDB. Here there are no field names, no inevitable column headings like “part number”. It might be there in some “records” but need not be.

Some younger people will tell you this is the future. That it’s flexible. It was the future a few years ago, until it was misused many times and firms found themselves struggling to ask the system “how many items did that customer buy?”

But to do this justice let’s quote Mongo: “MongoDB allows you to immediately start building your application without spending time configuring a database”

This is good dry humor to us. If you can’t spend the time configuring a database, what are you doing? Why are you storing what? And what’s the business plan?

MongoDB thus is sometimes the choice of inexperienced people intimidated by databases; we’re not. In fact we're rather fond of them.

The more classic solutions work well for most businesses. MYSQL can scale up to hundreds of millions of records easily with the right hardware, and to a size of many thousands of terabytes.

However, if you're using MongoDB, and insist on continuing to use it, we can help; we can create new Mongo servers, and query existing ones, and we can write front end query systems on the web or in your office to make getting answers out of it easy. Well, eaiser.

“But what’s beyond these classical data storage and query solutions?”, you ask.

Several things worth knowing: new methods and systems that work, like ElasticSearch, and systems in the cloud from the largest vendors like Google and Amazon, some of which query with SQL and some that don’t.

We like Elasticsearch for querying text (unstructured data) and it’s commonly used for looking into log files ( who has been trying to hack into your web server) as well as many other functions. A comparison of MongoDB and Elasticsearch here:

https://cloud.netapp.com/blog/cvo-blg-elasticsearch-vs-mongodb-6-key-differences

Going on, all of the larger cloud system vendors offer database services. First of all; ask yourself if you need this level of scale. The primary advantage is that they manage the infrastructure. The primary disadvantage is that your paying them to do it- and consider your data is now sitting on someone else’s computer. There’s no “cloud” as such you know :>) ; it’s just on a machine in a warehouse with “AWS” or “Google” on the front door.

Other advantages: if you’re a very large firm with lots of data and need to scale up: they offer effectively limitless storage, as well as high speed connections to the web, and machines with lots of RAM They also offer systems analogous to what we discussed above; SQL (classical) and NOSQL type structures, and thus your choice of services will be primarily dictated by the kind of data and the queries you want to run.

We favor Apache Spark for big data, but can work with most any system you have. This is a large and complex market, and we’re not going to try to summarize it all here, but are happy to help you understand it and make some decisions. Give us a call or write.