Use sql for storing

[leosartaj]

As discussed, rollcall should use sql. Please post on the database structure here.

[leosartaj]

@mafiya69 @sumitsahrawat

[0x6773]

Should I use previously made functions for json, or create my own?

[leosartaj]

If there is a function that can be used. Use it. I don't think you will find anything useful in func_json. But main might have some.

[leosartaj]

Also please explain the database structure you sent in #17

[0x6773]

It creates a db, and name of tables is name of subjects, Table contains three columns, class_no, class_tag and class_date, We daily add class_tag to subjects as needed. class_no increases by default from 1 by 1 and is a primary key. class_date is by default the date when the record is added. class_tag can only be one of the values of TAGS. Any edits to this structure is welcome!

Tag seems uninformative, I think it would be better if we named it something else, like status or something.

Another good idea would be to keep class no. unique across all tables. This can be done my recording the date, and period no. within that day. We then use these to generate a unique id for each period. This would provide more flexibility to further changes.

[leosartaj]

+1

[leosartaj]

On some thinking. This can cause some problem, incase, say a user decides to delete a period. Say user added by mistake. How will this query be handled then? Will every period number will be changed? Moreover, say I want to add a period that happened few days ago? How is this handled?

[leosartaj]

@mafiya69

[0x6773]

I think adding insert_period And delete_period will do this. insert_period will simply insert row according to date after increasing value of class_tag of each row whose date is greater than that[That date will be entered manually]. And delete_period will delete period and decrease the value of class_no of each row following it. Any other idea?

[leosartaj]

That would do it. But I was thinking this will involve going through each subject table. A lot of calls. @sumitsahrawat

[0x6773]

SQL increasing testing Time!

I'm still in favor of having a flat data scheme. Let's talk about it later on gitter.