![]() |
.. (לתיקייה המכילה) | |
Regarding using as few queries as possible... | |
This requirement is only meant for the actual task queries. Each function can be split into two sections: input validation and the actual task. You do not need to minimize the number of queries used for input validation. These queries can and should be separate. The queries you use to actually return the required output (the task queries) should be minimized in the sense that you don't want to make un-necessary queries. This requirement has two goals. First, you should try avoid doing any processing in C and perform as much as possible of the processing in SQL. We've learned from previous semester that attempting to minimize the number of queries also helps in reducing C processing. Second, it helps simulate real world conditions. In a real world scenario the DB server will be remote server which means that each query you perform is another network usage. Obviously, for performance reasons, you would want to minimize network usage during the calculation. As there are many ways to solve each question, there is no one minimal number of queries. The minimum depends on your way of solving the question. If you think you can use less queries, do so. Otherwise, leave it as it is. As long as your solution is reasonable it will be fine. |
Should we avoid views to reduce the number of queries? | |
No you shouldn't. If you have a sub-query that appears several times in a query it should be a view even though it is an extra query just because it is more correct. If you need to change the sub-query it is better to change a the view than go over the entire code and change all the appearances of the sub-query in the code. If a sub-query appears several times, make it a view. if a view is used only once, make it a sub-query. |
In the function addGroup, may we update the DB in 2 commands, one for each table? | |
Yes. Be aware that you are not allowed to transfer the new group_id in C programing. |
The 'Number' field is of type text, how should it be ordered by? | |
The reason of the 'text' type is that the leading zero of a number wouldn't be cut out. You should use the simple lexicographic order. |
In the sendMessage function, there is no restriction on users that want to send messages to groups that they aren't members on, is it right? | |
A new version of the HW will be published soon that adds this restriction. |
In the function removeGroup, may we update the DB in 3 commands, one for each table? | |
Yes. In all the functions that have to *change* something in multiple tables, you are allowed to execute a command for each table separately. |
In the function removeMember we were asked to check only if the user is a member of the group. Should we check that the user and the group exists as well? | |
No, it is enough to check only what you have asked for. You can assume that the DB is consistent and if the user is a member of a group then the user and the group exists in the DB. In real DB applications you would might want to add those checks. |
Could you provide some clarification about using an empty parameter in groupMembers and groupMessages | |
Yes. To get the memebers of all of the groups, you send the next command to the program (in the command line): groupMembers _ The parseInpute function will detect the "_" and pass a NULL pointer to your function ("groupMembers") instead of the string "_". In the function "groupMembers" you should check that you got a NULL pointer and build a query accordingly. |
In silence Users the user 0555000005 (Bar) appears, however she is a member of only 1 group and she sent a message there. How could it be? | |
This is not a mistake. You have been asked to return users that haven't sent messages in at least half of the groups they are members of. If a user is a member of only 1 group. Half of the groups will be 1/2 = 0. There always exists 0 groups that the user is a member of and he hasn't sent any messages in them (באופן ריק). If you write the query in the obvious way there is no need to check for this un-intuitively case. Writing the query with an equivalent case might result in that you will have to check for this case and maybe other cases as well. Obvious way: #GroupsWithNoMessages >= #AllGroups/2 |
In positiveGroup should we check only the lower case of 'yes' and 'ok'? | |
Yes. Don't check other cases. |