Parameterization and databases

During the next couple of days, all of the SQL will be parameterized using mysqli. This will make the database much more secure(protecting from SQL injection) as well as make the code more readable and editable.

We are also looking into alternatives for compatibility that require less updates and/or less databases. Our first idea was a user by user table, so 1 possibly 1000000by1000000 table. But Eric mentioned that adding columns can be very time consuming. The obvious alternative is a table with 3 columns, userA, userB and score. This would be a 1000000*1000000by3 table, which requires no column adds, but the 1000001st user will require 1000000 new rows to be added. The last idea we thought of was having a separate table for each user. So 1000000 1000000by2 tables. Not sure right now which one we are going to go with, or if there is a better option.

RCOS meeting

After our second presentation we were given a good idea regarding database efficiency. Now the compatibility table doesn't exist as one table, which requires a column add, which is as we found out very expensive. It is now a series of tables for each user. This allows for row adds instead of column adds, and makes searching for top compatible people very easy.

The issue of security was also brought up, and we are looking for good ways to protect from SQL injection/html injection in php/javascript.

Databases again

Recently I learned in my databases class the greatness of foreign keys with on delete cascade. So I decided to implement that in the system to make deletion of shows and people easier. While changing the structure, I had to remake all the databases, which allowed me to make new entries, and check a lot of my functionality that was made recently. Through that process I found a few bugs, and fixed them.