A simple DBMS and SQL engine parser

Question

hi guys;
i'm about to start an interesting c++ project described below...what i need is that you give me links ,advice and resources that could help me in my project...thanks for helping ...
here is the description:
Assignment:
In a nutshell, this assignment asks you to create a parse-tree for sample test SQL statements and actually create the underlying data structures to hold the data i.e. you are creating an extremely rudimentary SQL Engine (front-end parser) and a DBMS (back-end data structures). Our SQL Engine can be thought of as a bare-bone compiler. To test the SQL Engine and the DBMS, you will create a sample database. Finally (non-programming part), you will read up on the ODBC driver.
Note that a real compiler and a DBMS have functionality that is way beyond what I am going to ask you to implement. In fact, your DBMS software creation may disregard issues regarding efficiency ? those that couple the DBMS to the OS i.e. page buffering, blocking, concurrency, etc. Ours will be a data-centric view i.e. we will only focus on how best to save the user data. Treat this as DBMS-101 (It is more like DBMS-1.01).
Functionality:
Your SQL-Engine/DBMS software must offer the following capability-
Data: You must design data structures that will allow me to create tables and delete (drop) tables, insert tuples into tables, delete tuples from the tables and modify tuples values in tables possibly based on some criteria. Querying of course is the most important and frequently performed activity, but do NOT worry about joining tables or complicated queries. Data Serialization is of course implied by retrieval.
Meta-Data/Data Dictionary: In addition, I should be able to look up names of all tables that exist or the table definitions that exist and so on.
Future Requirements: I am being vague on this so that I may or may not add some small functionality later.
Software Components:
SQL Engine: Create a basic parser. Your parser should be able to parse the limited SQL statements that have been provided in Appendix A.
?     Include the test cases you used for the parser. Software Architecture and Implementation documents should also be attached.
?     Have the parser create parse trees for the sample SQL statements in accordance with your proposed grammar. The input could come from command-line or a stored file.
?     Print the parse trees (In-order and Pre-order) for sample input to present proof of correctness.
?     That completes the front-end of our SQL-engine.
DBMS: Propose a data structure, which will house the actual database. The back-end of the program will ?walk? the parse tree and create/fill in the data-structures in the back-end DBMS accordingly.
?     Data Dictionary ? meta-data details. I.e. lists details about tables and fields.
?     Data Definition ? creation of tables.
?     Data Manipulation ? update/modify, storage and retrieval of records.
?     Disregard issues regarding efficiency ? those that couple the DBMS to the OS i.e. page buffer, blocking, etc.
Database: Create a sample database to test your SQL/DBMS software. You must attach database schemas, tables with inserted values in your final submission.

Answer 1

I have no comments on the parsing of the SQL language. Without looking at Appendix A, I can't tell what you are being asked to do. However I do have a suggestion for a rather bogus back end storage that seems to fit the spirit of the assignment.
Create a directory named DB and in it keep files that are named things like
int_Employee_ID
string10_Employee_Name
where you follow the naming convention
DataType_TableName_FieldName
What this does for you is this:
To create a table just create files with the names and the datatypes that youwant.
To delete a table just delet files that have that table name as the secon parameter
The data dictionay is essentially a dump of the filenames in the directory.
Given that the data type in encoded in the file name it is easy to locate the ith element in any file for reading or writing.
Yes, it is bogus. It requires that you make dozens of disk reads to pick up all the pieces of a single record. Good thing efficiency was not listed as a requirement. You would NOT want this structure if you were looking for speed, or making sure that no tranaction gets only halfway done during a power outage.
But since the assignment is NOT about building databases but rather about parsing SQL statements, this layout gives you a fairly transparent way to represent your data and allows you to do nice bogus things like to create your initial data all with a simple text editor.
Since there are no joins to be requested of your system, all your SQL queries will essentially boil down into building filters that will run one or more of these lists and essentially create a list of indicies for records in a single table.