I have a simple question here regarding GroceryCRUD.
The question is: Is there a way to build a CRUD using Grocery when I have multiple relationship (JOINs)? For example: I want to have a CRUD for the following:
Table QUESTIONS
IDQuestion
IDRightAnswer
IDKnowledgeArea
Question
IDExplanation
One Record in this table would contain:
IDQuestion IDRightAnswer IDKnowledgeArea Question
10---------------2----------------------3---------------------------What is the color of the sun?
Table KnowledgeArea
ID------------Name
1--------------Phisics
2--------------Math
3--------------Astronomy
So, as this is normalized table, for those IDs (except for IDQuestion cuz it is PK and IDRightAnswer cuz its a FK) which is/are FK in the Questions table, I would like to have the correlated values (text) from Original table displayed in the grid rather than the ID itself.
So, using the same example, for the column IDKnowledgeArea in the table Questions (its a FK here) the CRUD would bring a combobox with the original values (text) in the table IDKnowledgeArea then I could chose it from there.
For example:
IDQuestion IDRightAnswer IDKnowledgeArea Question
10---------------2-----------------------Astronomy-------------What is the color of the sun?
All the CRUD tools I've seen doens't have such resource and although they provide good CRUD approach they never address this multi-relationship between the entities.
I appreciate any answer.
Thank you
Actually I gave a look on the documentation and I found this:
http://www.grocerycrud.com/documentation/options_functions/set_relation
Set a relation 1-n database relation. This will automatically create a dropdown list to the fields and show the actual name of the field and not just a primary key to the list. An example of this:
$crud->set_relation('user_id','users','username');
Thank you all
Related
I am designing a feature for a database, but I am stuck on design.
I have a table called AgendaItems, this table is a table with Agenda Items that could be assign to possible multiple users.
Users is a table that contains a record of user names, containing a fixed amount of 17 names.
How would I design these tables possibly another table that keeps track of who is working on what Agenda Item. Keep in mind multiple users could work on an agenda Item and users could work on multiple items.
I am not sure who to design this, and wondering if it would even work?
Thanks
I don't know if I understood your problem but I think your relationship is N-N.
So, you need to create another table (UsersAgendaItems). This table must contain the AgendaItems ID and Users ID, where both of then are FK.
Your PK could be a composite PK. This way you can know what user is related with what AgendaItems.
But I don't know if that is what you want. If this is not your case, please, try to explain a little bit more!
Thanks!
I'm making a website for a client but I stumbled upon a problem and I need some advice on it.
For each project, they want to have the possibility to set a variable amount of images and (sometimes) some corresponding text.
I was thinking about storing all of the information in one field, instead of making field_1 to field_99 just in case they need 99 fields.
// database column
'../fotos/foto1.png',
'hier komt tekst',
'../fotos/foto2.png',
'', (empty text)
'../fotos/foto3.png'
This solution has some disadvantadges, there must be better manners out there to achieve this.
What's the preferred way to do this?
Create another table (e.g. FOTO_CODES) with all possibly values of foto and generate id for them.
Create another child table that will have the master table record id and ID from FOTO_CODES table and FOTO data (Image).
It's called normalization.
The solution you described violates the principle of atomicity and therefore the 1NF. You'd have trouble maintaining and querying data in this format.
This is a classic 1-to-many relationship, that can be modeled in two ways:
1) Identifying relationship:
2) Non-identifying relationship:
Both have pros and cons, StackOverflow already has plenty of discussions on this topic.
I have a table that stores answers to checklist questions, where the checklists are in the format of yes, no, not applicable, or resolved.
Table: CHECKLIST_ANSWER
ATTRIBUTE_ID PK, FK
CHECKLIST_INSTANCE_ID PK, FK
TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved)
FAIL_REASON
ATTRIBUTE_ID is a foreign key to a table of questions, i.e. Was the part measured within some tolerance?
Now I want to model a checklist that would store quantity responses, i.e. How many incorrect dimensions were found on the drawing?
I feel confident that I can store these questions in my same table as the yes/no/na type attributes, but can I utilize the the same table to store the quantity value? Should I add a new column say QUANTITY_VALUE ? And then either QUANTITY_VALUE or TOGGLE_VALUE would be null depending on the attribute.
Table: CHECKLIST_ANSWER
ATTRIBUTE_ID PK, FK
CHECKLIST_INSTANCE_ID PK, FK
TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved)
QUANTITY_VALUE
FAIL_REASON
The goal of this database application is to move paper and excel checklists online and capture into Oracle to give provide more efficient collection of metrics and then better aggreagation of the inputs. Am I asking for trouble down the road by blending two into one table? Or should I create a table, CHECKLIST_QTY_ANSWER
If you have many options, you usually create a seperate table, only with an id and description (or name). To Connect these two tables, you insert a field into the CHECKLIST_ANSWER-Table, and define it as a foreign key, which references to the id (primary key) of the new table, I have mentioned first.
Hope it is clear :)
I don't see any problem with adding the new column to your existing table. I would include a check constraint that required that either TOGGLE_VALUE or QUANTITY_VALUE be null (but not both).
There's no good reason to create a second, nearly identical table, where only a single column varies. In my experience, that tends to lead to more problems than the single-table solution (it's practically an invitation to use dynamic SQL).
I definitely would not re-use the existing column (as suggested in another answer), as that would prevent the use of a foreign key on the toggle value.
If I understand your question correctly you're looking for advice on how to store the new type of answers in your schema?
Since this is a new type of answer you'd need to denote that the format of the data is now different from your y/n/na answer type. You could do this by adding another table CheckListAnswerType and a FK in your CHECKLIST_ANSWER table.
However, your CHECKLIST_INSTANCE_ID could easily indicate that this is a type of checklist that follows a certain answer pattern. I'm not sure about the rest of your schema buy you could have a CHECKLIST_INSTANCE table that specifies it's answer type...
Your TOGGLE_VALUE could follow a numeric scheme for your new answer types and with the a fore mentioned CheckListAnswerType you could and would have to always take this into account when querying the data to make sure you weren't picking the wrong answer type given the question context so that you didn't get a Yes value while looking for your How many incorrect dimensions were found on the drawing? answer.
I would think all of that would be fine, UNTIL you start wanting to store answers of a different data-type. Then it would be time to redesign schema.
TL;DR: If you're using the same data-type for answers then you would be okay re-using the existing schema (column) while adding a way to tell the answer, or question/answer, types apart to query accurately. If you want to store other data-types in TOGGLE_VALUE, implement new schema objects to do so. Don't try and force other data-types into the current schema if you can avoid it. Also if you did this consider renaming TOGGLE_VALUE as it no longer represents a Toggle. answerValue might better fit the new design.
I'd like to hear opinions on if it is better to keep forum categories and subcategories in the same table or in two separate tables...
Let's say you have a table ForumCategories. By adding a colum ParentId referencing the PK Id in the same table you could easily keep both the main categories and subcategories in the same table.
Alternatively, you could create a separate table ForumSubCategories and make the Id on that table a FK referencing PK Id column of the ForumCategories table.
Both solutions would work but what are the pros and cons of each solution?
Obviously, this is a more generic question that can apply to many other scenarios I just couldn't come up with a better phrasing in a hurry...
I can't think of any benefits of using 2 tables. Using 2 tables is going to constrain you to a 2 level tree. If you look at things as objects, then subcategories really are just category object. So put them in the same table. The 1 table structure will be simpler to design around and develop queries for.
If you know for sure that your forums will have only 2 levels of categories, then having 2 tables is reasonable.
Though storing categories in one table with foreign key to itself, basically, allows you store a tree of categories with virutally unlimited levels.
If they are the same entity (Category), you can link to itself. The parent would have a null for the parent ID or it could be linked to itself. This limits you to only one level unless you have a second table to handle the many-to-many possible relationships.
They must have the same fields or you're going to have unecessary fields for one or the other type. A separate table is why you would do this because they're not the same.
This is typical for an employee table. The supervisor is another employee record.
I'm a total newbie when it comes to SQL. I'm making a site in ASP.NET for doing surveys. A privileged admin user will be able to build a survey. Then lots of other people will respond to the survey.
Once I have the set of questions for a new survey, what is the best way to automatically construct a table and an INSERT query to store the responses?
UPDATE
Thanks for the quick responses! I'm still a little unclear on how survey responses would best be stored in this scenario. Would each respondent get a row of the table? And if so, would the columns be "answer given for question k of the survey identified by the entry in column 1"?
You dont want to build a new table for each survey.
Create a surveys table (SurveyID, UserID, Name, etc)
Create a Questions Table (QuestionID, SurveyID, QuestionText, SortOrder, etc)
optionally, Create an Options table, assuming you have multiple choice type questions (OptionID, QuestionID, OptionText, etc)
Then when someone creates a survey, you insert into the Surveys Table, referencing that person's UserID as the foriegn key, then get the newly inserted SurveyID,
Then for each question they add, insert it into the Questions table, using the above SurveyID as the foriegn key.. and so on.
EDIT to answer your edit:
Sorry I should have followed through to cover storing answers as well.
You would want another table called SurveyResponses (ResponseID, Name, etc)
And another table I'll call ResponseAnswers(ResponseAnswerID, SurveyID, ResponseID, QuestionID, AnswerText/AnswerID) Where SurveyID and ResponseID are foriegn keys to thier respective tables, and depending on wether users have multiple choice, or enter an answer, you would either store thier answer as text(varchar) or as another foriegn key to the options table.
You probably don't want to be programatically generating the schema.
Instead, have a table for surveys, for questions (which belong to surveys), for response sets (one per user), and question responses (which belong to the response sets).
I'd think of a couple of options:
Create a one-to-many Survey table and Question table, where each Question has a column DataType that has a code of the response data-type we're expecting, and optionally some other columns / related table of available options, a column that specifies if this question is multi/single choice, mandatory/optional question etc. The Answer table's Answer is serialized/desieralized/indexed/formatted etc. according to the question data-type
Consider using NoSql database to store the survey data in a similar manner
You wouldn't automatically construct the table. The table would be predefined, and the answers would be added to them. I think the best way to get started with ASP.NET these days is to dive into MVC & Linq (http://asp.net/learn)