No-SQL. When our logical assumptions become illogical

SQL or Structured Query language has been the prevailing mode of database organization for over 40 years. The fundamental concepts that form the basis of SQL were introduced in the early 1970’s.  And fifteen years later, in the mid 1980’s standards were introduced that enforced uniformity for all SQL database solutions from a wide variety of the most respected and pervasive software vendors in the industry:  IBM, Oracle and Microsoft to name the most prominent.  What more could we ask for?

  • an overwhelmingly logical database structure,
  • accepted by the leaders of our industry,
  • with standard that promote uniformity and compliance across commercial software products.

But beginning in 2006 and more recently, we find two forces emerging that are challenging the leadership, acceptance and viability of  SQL.

The first emerging force is “big data”.  We are beginning to see databases of 500 billion or more records.  These databases span disk storage devices and even span computers themselves.  For the past 40 years, it was reasonable in traditional SQL to make logical connections between related data sets.  For example:

  • An order and the underlying order items are related.
  • The customer and customer payments are related.

But the tables in our databases are beginning to take on sizes that exceed our wildest imagination.  And while the task of joining or connecting these “related” tables seems logically sensible, the practical task of doing so for immense data tables is no longer feasible.

Faced with this dilemma, we begin to question the logical purity of SQL and revisit the most fundamental of our data organization questions and assumptions.  Rather than continually splintering and reassembling the components of a logical data record when needed, why don’t we simply store all related information in one record.

We are finding that the very cornerstone and foundation of database logic is being turned on its head.  As is frequently the case, once we challenge our most fundamental assumptions, absent this foundation, elated ideas also begin to give way.  Things that were previously difficult now become easy.  But the contrary is also true.  Those things which were easy with SQL become more difficult.

In subsequent blogs, we will construct a new logical vision.  We will explore these logical issues, the benefits and costs, as we leave the accepted real of SQL and enter the world of No-SQL.

Advertisements

Password performance anxiety – a recurring nightmare in the internet age.

What was that password again?

You know the feeling.  You click on a website, one you have not used in a few weeks.  You break out in a cold sweat as the website asks you to enter your user name and password.

“Which user name did I use?”  “What was that password again?”

Each one of us has between 20 and 150 user names and passwords to remember.  How could that be, you ask?  Well we each have a bank, or two, or five.  We have Facebook, Twitter, Linkedin.  We have Amazon, Ebay, Barnes and Noble.  Our ftp password, Dropbox, the company logon at our job, Gmail and Yahoo sign-on. Brokerage firms, 401k or IRA plans,. our dentist, our doctor, Snapfish, the health insurance site, university alumni organization, student loans, several airline frequent flyer sites, Netflix, Cable TV, Our wireless carrier, utility, and countless retailers and department stores.  The list goes on and on.

To make matters worse, some sites require special characters for user names and/or passwords.  Some do not permit these characters.

Some sites require a password greater than 6 or 8 characters.  Others consider these to be maximum lengths you cannot exceed.

Some sites require both numbers and letters.  Other sites permit only one or the other. ATM codes are a great example of numbers only.

Some sites are case sensitive and require some letters of each case.  Others do not.

Some sites REQUIRE you to change your password every few months.  Others do not

Truthfully, as I recount the various requirements and differences, I too am breaking into a cold sweat.

How then, do we manage our user names and passwords?

An essential part of online life, but are there alternatives?

Before we begin to suggest answers, we can all agree that the effective use of passwords is an essential part of our online life.

Technological innovations

Well, there have been discussions about replacing passwords with voice recognition, or finger prints, or retina scans.  But these innovations are a ways off.  And they have their shortcomings as well.

On more than one occasion, my son or daughter or wife has asked me to sign on to one of their accounts to retrieve some information or enter a transaction on their behalf.  With these proposed types of passwords, our ability to help out those who are close and trusted would not be possible.

Password keeper software

If you were to key the above 3 words into a Google search, you would see countless pages of software that enable you to enter passwords into a local or internet database that is, itself, password protected.

But who among is us is looking to buy yet another software tool?

And we want to be sure that this tool is accessible from our office computer, home computer, tablet, and smartphone.  If the software is accessible from all these locations, we assume that the software is located in the cloud.  And if this is the case, how do we ensure that the password keeper itself will not be compromised.

Nowadays, many sites require us to know more than our password.  We need to remember answers to bizarre questions such as which hospital our maternal grandmother was born in or what the middle name of our best friend in kindergarten was.  This information needs to be stored someplace as well.

Lastly, we would want this password keeper software to be usable by other members of our family.  By this we mean that they should be able to store their own passwords.  We also mean that we want them to have access o our passwords if we want them with our permission “borrow” to access our account.

60 days are up, time to change your password… or else!!

There are two schools of thought regarding the need for frequent, required password change.  Of course, there is some truth to both schools.

The good thing about required password changes is that if a user is no longer active at all, the account is more likely to be unusable.  In addition, there are those who believe that frequent password changes will foil hackers and others with ill intent.

However, the reality is that when sites require frequent password changes, the user makes the minimal change to the password each time.  570test for example becomes 571test, 572test, 573test for each successive change.  What’s worse, the users tend to write the password down in a place that is easy to find.  I have even seen users write down the password on a post-it note and stick it to the computer monitor.  So much for improved security.

Like socks, one size fits all

Some users will try to use one password for ALL websites.  This would certainly make the password easier to remember.  But is this practical?  And is it secure?

From a standpoint of practicality, the syntax requirements of various websites make this idea not workable.  There are too many different requirements from one website to another.

As for security, there are those who believe that one password would give a clever hacker unlimited access to all of our financial and internet life.  There is considerable truth to this.

My favorite solution, the root password approach

We now find ourselves at the end of the Blog with a thorough understanding of the password issues.  This would be the perfect time to propose a relatively simple, straight forward solution to the password conundrum.  And we shall proceed to propose one here.

The key to our password solution is to identify 2 or 3 different “root” numbers, one of which you can imbed into any one of your passwords.  For example, three possible root passwords could be:

the month and day of your grandmothers birthday,  e.g. 0327

the address of your dorm building  in college,    e.g. 4815

the license plate number of your first car.  BSG431

You can incorporate any of these “root” numbers into anyof your passwords, and even write them down.  But when you write them down, you don’t use the literal “0327”.  You abbreviate it as “BD”.  For example, your password to Amazon.com might be pur0327ch.  When you write it down, you write it as purbdch.

In this way, you can write down each of your websites, account numbers, user names, and passwords. You can even  write the 2 or 3 or 6 questions and answers that web sites require for additional authentication.  My suggestion here is to write down that answers only, not the questions.

But where do you write them down?

The most secure place is to handwrite them on paper and store them manually.  The difficulty here is that you want the most current password every place you use your computer.  At work, at home, your phone.  Another problem is that over time, the hand-maintained copies will not all share all of your password information.  Another problem is handwriting – and mine is not good. I do not advocate this approach.

The next alternative is to type them into a Word document and store them on the local drive of your computer.  The difficulty here is that you want them accessible at home and at work and on your phone.  And when a password changes, it must be changed on every copy.  If you have different copies of this file, my suggestion is to designate one of the copies as the master file.  And only make changes to this master copy.  You can then copy the master to the other files.

Incidentally, you should always password this document that stores the other password information.   This provides another level of security.

Some final words of advice

Do not store this file that contains passwords on a notebook computer, flash drive, tablet or other portable device.  If you must store it on this device, make sure that the file is itself password protected.  And remember this password.

Passwords can contain upper/lower case, numbers, letters, and special characters ($, %, #, etc. )   Always choose at least 2 of them.  I have a personal preference, but I will not share it here because this would give readers of this Blog the inside track on my personal approach to security.

Final bit of advice, be diligent in the maintenance of your list of passwords.  This is the key to overcoming password performance anxiety.