Propeller Chip & Database

johnnybgood115

All,

Is there a recommended method / format for storing a database like structure of information that the Spin programming language can interface with?

I'm developing an application which requires users to select a wide variety of options and these options are then used to control different switches and relays for varying time periods.·

The easiest way may be to develop a .NET program using MySQL or other database system, but this means I'll need to have a PC alongside the Propeller board.· I'd much rather store all the information in a SD Card, for example, and allow my Spin program to read/write from there directly to a display.

How is this best accomplished with the propeller board and are there any tutorials/documentation on this?

Thanks,
John

Paul Baker

Anything is possible, but some things are easier than others. Can you be more specific on the database requirements? Such as: are the fields all fixed size or vriable size, if you have variable size fields, can they be made into fixed by placing a reasonable upper limit on thier size? How do you plan on accessing the database, are you able to do just index fetching or do you need search capabilities? And if you need search capabilities, is this just on one field or do you need to be able to search any field?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker

johnnybgood115

Paul Baker said...
Anything is possible, but some things are easier than others. Can you be more specific on the database requirements? Such as: are the fields all fixed size or vriable size, if you have variable size fields, can they be made into fixed by placing a reasonable upper limit on thier size? How do you plan on accessing the database, are you able to do just index fetching or do you need search capabilities? And if you need search capabilities, is this just on one field or do you need to be able to search any field?

Yes .. lol ..

They're all of fixed size including text and numerical quantities. There will most likely be an upper limit of 10 characters for text and 3 for numbers. I'd like to be able to search and display just the text names; but give a user the ability to add/edit all attributes of each entity.

Example entity:
ID
Name
Part1
- time
- pin
Part2
- time
- pin

Paul Baker

Ok, a few more questions before getting into specifics, Am I to understand that you'll have records which will have a variable number of sub records? Ie, ID=1 has 1 Part, ID=2 has 4 Parts, etc and you want to be able to have the user add a new ID as well as sub records onto an ID? Will they be able to delete IDs or sub records? Are these parts likely to be located in multiple IDs and changing a part's data it would be desirable to have this updated through all IDs which contain this part?

There are several ways of organizing databases and depending on the type of information thats in it and how you will be using the database in day to day operations helps determine which type of structure to use. The more explicit you can be the better.

To give you a little pre-info, the database is going to be a flat file. Tthis is the easiest since data structures aren't inherently supported by the Propeller and the SD library only supports one file open at a time. For the type of database where there's not going to be much if any similiarity between records such as a customer database, it's best to just throw all the data inline in one continuous data chunk. But if you have a large interelational database, such as a pick-and-place machine where the same component is used on multiple boards it's best to maintain seperate spaces for the board and parts and the board has pointers into the parts space. This way if a part needs to be substituted due to supply issue, then it only needs to be edited in one place and that automatically updates all boards instead of having to manually search each board to see if it contains the part and updating each instance seperately.

So being explicit as possible on how you intend on using it will be helpful for creating the most optimal database structure (simple where we can get away with it, more complex where it is necessary).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker

Chuck Rice

Would Robert Quattlebaum's "Settings" object work for you? It stores the data in the EEPROM, so you would be limited to eeprom size.