I am working on a project that involves putting together a database of chords/keys, and I'm wondering what you guys think is the best way to categorize each chord/key. For example, if I want users to input a chord into the database using several dropdown menus, what menus/choices do I need? The goal is to make the information easy to group/sort/filter in meaningful ways, however, I am far from an expert on music theory, so I would like to know what you think are the most meaningful ways to categorize/break down the data.

Here are the menus that I have so far, do these make sense? Am I even close?

  • Root
    • A
    • B
    • C
    • etc.
  • Accidental
    • Sharp
    • Natural
    • Flat
  • Quality
    • Major
    • Minor
    • Diminished
  • [Unsure of terminology here]
    • 3rd
    • 5th
    • 7th
    • etc.

Thanks in advance for any suggestions/guidance!

  • 3
    Understanding the circle of 5ths would probably help you a lot.
    – Dom
    Commented Feb 20, 2014 at 14:15
  • I like the way you present it now. Except I would put diminished in the last category and call that type or extra.
    – dorien
    Commented Feb 20, 2014 at 15:03
  • You might want to look at the Chordbot iOS/Android app for inspiration. It lets users put together chord progressions, so its UI for selecting chords is a major part of the app. chordbot.com
    – Kevin
    Commented Feb 25, 2014 at 1:52
  • May I ask what is the purpose of the data base is? When one has an understanding of chord construction a data base seems unnecessary?
    – Fergus
    Commented Feb 25, 2014 at 20:16
  • @Fergus, I am building a web-app that will allow users to query the database in a friendly, easy-to-use way for a musician (targeting amateurs and hobbyists) who is not necessarily knowledgeable in music theory. An example would be: two beginner/intermediate guitarists jamming to a chord progression they're not familiar with and one wants to play lead over it, so he puts the chords into the app, the app queries the database and returns a few possible keys that they might be playing in, and then renders a guitar fretboard showing which notes on the fretboard are in that key. Commented Feb 26, 2014 at 0:49

6 Answers 6


I'll give you the off-the-cuff perspective of a guy who got his degree in piano and then spent the next 30 years in software design. :)

Let me say first that it is important that you understand that the manner in which the data are stored is not the same thing as the manner in which they are displayed. It looks like you have a pretty good start on the way that they are displayed.

Now, are you asking to have a user fill up a database with chords, or put in the characteristics of a chord and get output as to how the chord is spelled? The first is what you're implying, but the second might be more useful. I'll assume the second, and give you my first impression of how I would go about it.

I would consider starting this way. Allow the user to type in the letter A-G. Have two option buttons (radio buttons) in a set, one for sharp and one for flat. Then use another set of option buttons for major, minor, dimished, and augmented. Finally, have a check box for 7th.

Leave other chords until you get these basics working. This will give you all of the triads and all the 7th chords.

Now, there are two ways to store the data. A "flat" database would simply have a record for each different chord, which would have the spelling of the chord. A "normalized" database would have three separate tables: one for chords, one for notes, and one for which notes go with which chords. Notes (a table called Notes) has two fields: a key (just a number, a different number for each record or row in the table) and a note name. This table contains all the different possible notes in the scale, including all the enharmonic ones. (Enharmonic notes are notes that are spelled differently but are the same pitch, for example F# and Gb.) Include all the double sharps and flats as well; you'll need them for augmented and diminished chords with a sharp or flat root. For example, Ab diminished is Ab-Cb-Ebb, and G# augmented is G#-B#-Dx. Then, store all the chords in a Chords table. (Skip chords whose root is a double sharp or flat; they theoretically exist but come up rarely if at all in practice) Each record in the Chords table has two fields: a key and the name of the chord. Finally, you tie these together with a ChordNotes table. This one has three fields: the key of the Chords table and the key of the Notes table, and also a number which shows the place in the chord for that note, from bottom to top. For example, in C major, C is 1, E is 2, and G is 3.

I'll give an example to show how this works. Suppose your user has selected C major as the chord. You look up C major in the chords table; let's say its key (table key, not musical key) is 14. You then go to the ChordNotes table, and find that there are three records with a Chord key of 14; these records have 3, 5, and 7 in the respective note key fields. You then go and find the three records in the Notes table with keys 3, 5, and 7, and you have your chord.

Putting that example into SQL (I'll just make up names for the fields in your tables; you can use whatever field names and table names you want in your design):


The result would look like this:

-----------  -----------  
C Major      C  
C Major      E  
C Major      G  

That should give you a good base to start on. You'll need to work out how to get the key of the chord that the user selects from your UI (user interface), and how to display the result to the user. However, if you implement all this, you'll learn enough so that you'll have some idea of how to implement refinements that suggest themselves. Hope this helps, and good luck. :)

  • Hey, I'm currently at work (as an accountant, so in no way related to this question), but I will read through it ASAP. A quick read-through looks like we're very much on the same page, and if you would like to see how the database is set up (5 tables, Key, Keychord, Chord, Chordnote, and Note), please check out the repo: github.com/jackerman09/what_key_v003. I'll read through your response very carefully later and get back to you, thanks again! Commented Feb 20, 2014 at 15:36
  • You may find that key and keychord are unnecessary, although I may not have thought this through fully too. Why do you have them?
    – BobRodes
    Commented Feb 20, 2014 at 15:45
  • One of the applications that will be built on top of this database (you can see a rudimentary, non-database, version of this at whatkeyamiin.com, which I built ~1 yr ago, but am now rebuilding from scratch). I plan to bring in a "music admin" to work on the new app, who would have the role of approving chords & keys submitted by users, which would allow them to enter the "public library" of searchable chords/keys. Does that interest you (or anyone else reading this) at all? Commented Feb 20, 2014 at 18:34
  • Why would users have to have their chords approved before being able to look in the library?
    – BobRodes
    Commented Feb 20, 2014 at 20:06
  • The user can look in the "library" of public chords at any time, but only those chords that have been approved by the "music admin" will be viewable in the library or included in the apps utilizing this database. This is done to ensure that the created chords (and the notes it includes) are correct before becoming available for public use. While I have a basic knowledge of music theory (and I am developing the app on my own, though I am open to collaborators), I am not qualified to approve/correct chords submitted by users. Commented Feb 20, 2014 at 21:30

The fundamental idea of a chord is that there is a pitch, the root, and then a series of other pitches that have relationships to that root pitch, and implicitly, to each other.

I wouldn't make a big distinction between the natural notes, and those with alterations on them as you indicated in your bulletized list, but this could be argued either way.

I'd look at it as:

1) The user selects the pitch class for the root

2) User selects from {major, minor, sus2, sus4, no-third [*]}

  • this is the characteristic of the "third"

3) The user selects from {P5, aug, dim, no-fifth? [*]}

  • The default is the perfect fifth

4) The use selects from various extensions {7th, maj7, 13th, flat-9 ...}

  • Here things start getting really complicated, and you'll have to decide what range of music you want to support.
  • maybe you want a set of independent checks for this.

I only see two complications:

  • Usually a diminisished chord impilies a minor third, but not always; sometimes, notably in jazz, you want a major third with a flattened fifth, so disentangling this case might be harder.

  • Defining the range of chord "extensions" you'll need to have an idea of the scope of music that will be going into the data base, or a flexible system (vanilla strings maybe?) that allow for arbitrary extensions.

An option for handling the first case is

1) root pitch class

2) select from {major, minor, sus2, sus4, aug, dim, no-third [*]}

  • major/minor/sus2/sus4 implies perfect 5th

  • aug => major 3rd, dim => minor third

3) select extension

  • as above but include the various flat-5/sharp-5 options here.

[*] depending on how esoteric your music gets you may need additional concepts.

  • 1
    Just so everyone knows, your response is from the perspective of jazz theory and mine from that of classical theory. While the jazz approach is entirely valid, what you would or wouldn't do from a jazz perspective, and for good reason, might not apply from a classical perspective, also for good reason. For example, jazz doesn't go in much for different spellings of the same chord, and classical often does. This difference is driven partially by the fact that jazz rarely uses simple triads, and classical uses them more often than not.
    – BobRodes
    Commented Feb 20, 2014 at 15:56
  • Also, your "major third with flattened fifth diminished chord" wouldn't be analyzed that way at all in classical music. In jazz, this chord generally occurs as a "dominant 7th flat 5" chord, with the added minor 7th. Such a chord generally occurs in classical music as an "augmented sixth" chord, specifically a "French sixth" chord, and spelled entirely differently. For example the D7b5 chord C-E-Gb-Bb would be C-E-F#-A# (hence "augmented sixth") and would nearly always resolve chromatically to a B chord in root position.
    – BobRodes
    Commented Feb 20, 2014 at 19:47
  • As I understand it, the b5 chord usually functions in jazz as a substitute chord for the V in a ii-V-I progression, where the b5 root is a tritone from the root of the V chord, thereby making a nice chromatic ii-iib-I progression.
    – BobRodes
    Commented Feb 20, 2014 at 20:00

The optimal schema for any database largely depends on the type of queries. Think about that the user may ask from such a database. Maybe which chords are the good potential candidates to follow it in a chord progression? Then you need to read some theory about chord progression rules, and support queries along these rules. Here may be some hints to start from.


From the OP comments:

I am building a web-app that will allow users to query the database in a friendly, easy-to-use way for a musician (targeting amateurs and hobbyists) who is not necessarily knowledgeable in music theory. An example would be: two beginner/intermediate guitarists jamming to a chord progression they're not familiar with and one wants to play lead over it, so he puts the chords into the app, the app queries the database and returns a few possible keys that they might be playing in, and then renders a guitar fretboard showing which notes on the fretboard are in that key

You need to define your goal more strictly before writing any more code.

The main point is weather your app can handle non diatonic chord progressions.

What will happen when someone inevitably puts in the 12 bar blues chords? (I7, IV7 and V7) Will your app be smart enough to recognize this extremely common non diatonic progression? and suggest the minor pentatonic, major pentatonic, mixolydian, blues scale, lydian dominant etc built from the roots of each chord as valid and common choices?

will it be smart enough to give the minor pent. as a valid choice for a dominant chord in this context? Will it know not to give this suggestion for 99% of other occurrences of dominant chords?

What will happen when other popular non diatonic chord progressions are input such as the Andalusian cadence? (http://en.wikipedia.org/wiki/List_of_popular_music_songs_featuring_Andalusian_cadences)

Will the app be smart enough to recognize that the phrygian dominant is an appropriate scale over the V chord?

What will happen when the user puts in "Hey Joe"?

These very common 'beginner' progressions will be the acid test. If your app can't deal with them then it won't be much use to anyone.

If you decide to avoid the complications of non diatonic progressions then it can be much simpler to achieve. In that case there's really no point having the input system allow, say a diminished chord as that is never a diatonic chord. But your whatkeyamiin.com site basically already does this..

If you go down this route I'd suggest simply having an image of the circle of fifths. the user selects chord after chord say, G, then C then Am then Em, as each additional chord is selected the possible diatonic chords reduces (non diatonic chords 'black' out) and the possible key become highlighted.


The first thing necessary to formulate your thesis is to understand your data and what other approaches have already been implemented. If you are thinking of a dynamic or interactive approach take a look at chords and scales identifier. The reference to "Lotus Music" was useful, but it presents a static interface.

  • Thanks for your input! This question is from a while ago, but if you're curious as to the outcome, here it is: www.whatkeyamiin.com :) Commented Aug 24, 2019 at 2:54

I just wanted to chime in and say that Databases are designed for items that are subject to change. Chords, Notes, Keys, etc don't change. So last thing you want in any music application is latency. Computers are built on mathematics, and so is Music Theory, so they get along quite well. Midi Messages are byte arrays.. And computers love bytes, they take very little space, and can be processed/streamed with minimal latency. I believe these things should be hardcoded as the computer can process millions of these types of instructions per second with no latency. A trip to the database will cost you milliseconds that add up.

So the only thing to begin is to describe each element as a class. For each element we want to keep them simple but avoid writing the same code twice. I'm building a midi application from scratch with no knowledge of music theory, and learning some music theory along the way.

Basically you just need a list of notes, each chord is made up of notes a certain distance from each other. This makes it easy to describe as a integer array

(List<int>)Notes.Add(new Note { Name="A", Pitch = 1, AltName="A" };
(List<int>)Notes.Add(new Note { Name="Bb", Pitch = 2, AltName="B Flat" };

Notice the Notes know nothing about Scales, or Chords. Now we describe a scale

 Scales.Add(new Scale {  Name = "DIATONIC_MINOR_SCALE", Data= new int[] { 0, 2, 3, 5, 7, 8, 10 } });
 Scales.Add(new Scale {  Name = "AEOLIAN_SCALE", Data= new int[] { 0, 2, 3, 5, 7, 8, 10 } });
 Scales.Add(new Scale {  Name = "DORIAN_SCALE", Data= new int[] {0, 2, 3, 5, 7, 9, 10 } });

The numbers describe the distance from the root (notice the scale doesn't care nothing about a root note)

And finally a chord (you could do progressions using this same format)

  Chords.Add(new Chord {  Name = "DIMINISHED_SEVENTH", Data= new int[] { 4, 6, 9 } });
  Chords.Add(new Chord {  Name = "SEVENTH_FLAT_FIFTH", Data= new int[] { 4, 6, 10 } });
  Chords.Add(new Chord {  Name = "MINOR_SEVENTH_FLAT_FIFTH", Data= new int[] { 3, 6, 10 } });

Notice how the chord doesn't care about root notes, or scale.

I believe this is a good start for anyone looking to work with music theory in software engineering.

So im not smart enough to know how to find which chord the user typed, but since these are all list of integers. I think you can now know the root note, chord(s), and scale of any input. I think you could just brute force and find many possible chords. You could just store the users notes as a byte array in the database (the root note is assumed to be the first) and leave the "thinking" stuff to the compiler.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.