Design Choices For Project 1, CS4432

Anthony Andrade
Elizabeth Cash

We have decided to store our data as fixed length strings, all which reside 
on one line of a file.  The schema, db.cfg, is a schema which names the 
database, the # of fields, type of field, order in record and meaning of 
each field.

For this project we decided to use the fixed format for ease of programming.  
However other formats would have been more desirable.  In the Variable format 
the record is self-describing, considering that we were modeling a database we 
thought thatwe would not have sparse records, repeating fields, or evolving 
formats, all which are great for the variable format.

We have decided to mark deleted files as the "#" sign.  This decision was made 
based on teh tomb-stone idea.  Once a save on our updated database is made the 
tombstone would be deleted, but until then inserts can be put optionally first 
in that line, or if there are no tombstones then at end of file.  Because it 
was not  a precursor that out records were stored in a any specific order we 
have not bothered with any specific model for keeping track of records other 
than the records Key (as in the example the ID# for movies).  This would be 
how we would sort the database, and find information.

We did not decide to record the ID within every record , and then follow 
pointers to find a sequential route through the database, because it was 
not nessaccaryt for this project as it was described.

Within our design a few things turned out really well, while we realize that 
other parts need work.  When we begin discussing implementation we decided upon
an end of file character "^"  However we soon found that it would be easier to 
use the predefined file.eof() function provided by iostream.h  We also had an 
issue while creating the database that if we were to start the application over
the database file would still be in the system and append to the old file of 
same name.  This has been fixed since by rather than appending the records, 
they are first being made and tehn appended.The next issue our database has 
is lack of data format parsing.  This would cause issues in  a real 
world database, but could be addressed within the application and not 
within the application rather the DBMS.  The final issue with MyDB is poor 
error returns.  They are ambigous and therefore not very helpful to a user.  

We do believe that parts of our implementation are very good.  this would 
include our method of searching through the records.  We use our search key 
goto offfset of record	and therefor do not have to read through hte entire 
record to find the information we need.  We implemented the database so that 
no matter which schema the user makes up, it should except it.  Which is 
helpful so that the user does not have to fiddle with the code everytime 
they come up with a new schema.


