I am developing a website which will collect and store information for users.
I need to create a table specific to each individual user on registration to store the information they are searching for using the website. The table created will be named after the newly registered user's username.
Then when the user is logged in and runs the search, the data collected will be stored in a database using a MySQL insert query where the table name is a variable containing the logged-in user's username which will also be the table name.
I am an amateur developer and have searched everywhere to try and find a solution but I cannot seem to find anything evenly remotely similar to my problem.
Thank you in advance for any help!
Creating tables on the fly is more trouble than it's worth and very much swimming against the tide with any SQL database.
The reason you haven't found any docs about the approach you mention is because this problem is generally (almost without exception) solved best by having all the data in one or more tables, and including a column to specify which entity (user) the row is associated with. In your case, this might be an email address, or a username, or just a sequential number.
E.g.
| user_id | email | first_name | last_name | fave_color |
- - - - - -
| 1 | "a#b.c" | "anton" | "aardvark" | "red" |
| 2 | "b#c.d" | "miles" | "o'brien" | "infrared" |
| ... | | | | |
First take name from user like:
$fullname="$fname"."_"."$lname";
Then, write a query like this to create a table of that name
$sql="CREATE TABLE $fullname(ALL THE COLLUMNS YOU WANT TO CREATE)";
$result1=mysql_query($sql, $db_link);
this query is from my project. Works fine in wampserver.
Related
I've been tasked with creating a physical event logging system, where an employee will create an event based on a physical event that occurred purely for logging purposes. For example, say they answer the phone - they must then create a "Phone" event and fill in who called, why, and when.
Each event will have the same input fields accessible to enter, however some of them require additional input fields that are only accessible to specific event_types.
Here's a snippet of the schema:
table: event_types
| column | type |
|--------|---------|
| id | integer |
| name | varchar |
table: events
| column | type |
|---------------|----------|
| id | integer |
| report_id | integer |
| user_id | integer |
| event_type_id | integer |
| date | datetime |
| details | text |
| locations | json |
| people | json |
| data | json |
Basically, the event_type_id can be one of 50+ event types. Only 15 of them will require unique fields. These event types are static when the app is installed (they are seeded into the DB), and users won't be creating them in the app itself.
The locations, people and date field will be available inputs on every event. My initial thoughts was to have a data json field to store additional input field data.
However, I'm not sure if this is the best way to handle unique input fields depending on specific event_type_id's. I'm also not sure how I'll handle validating these unique fields based on the event_type_id.
Would it be best to hard-code event_type_id's and then assign validation rules depending on which event_type_id an event is created with? I'm also wondering how to handle this when rendering the form view to load in the additional input fields.
I've also thought about storing the validation rules and the view name inside the event_types table, but I thought doing so may be bad practice since I'd need to update the event_type record in the database anytime I want to add another field.
I'm really hoping for some advice from anyone who's had to implement handling unique fields within their database - I'm really not sure how to handle this properly... Thanks so much for your time!
EDIT: I've went with a hybrid - a very limited version of the Entity-Value-Model and json data fields. I'll be posting my complete implementation in the coming days for others in case it helps anyone.
I am currently creating a Filesharing System for learning reasons in Laravel. Currently it is possible to upload Files and then to Download them later. Now I would like to extend it in a way that one File can be downloaded by multiple (but not all) persons.
Currently I have a User Table and the user id is referenced in a File Table. That way I know which File belongs to which User.
The file Table looks kinda like this:
id | filename | user_id |
1 | doc.php | 2 |
2 | fly.php | 4 |
3 | dog.jpg | 3 |
4 | cat.gif | 2 |
And so forth... That way I can just check if the user_id is the same as the Authenticated and logged in User.
The problem is I couldnt quite figure out how to make a file accessible to multiple users (10-20).
Do I just create a new Table which will look like this:?
user_id | file_id_1 | file_id_2 |
1 | 3 | 6 |
And everytime a additional file is assigned to a User a new Column is created?
To me this seems like very bad Data Schematic.
K
As #Greg has already commented you are best to use a pivot table to link the files and users to each other.
This will allow you to use hasManyThrough relationship to get all the files that are accessable by a user and all the users that have access to a file
https://laravel.com/docs/5.7/eloquent-relationships#has-many-through
I'm trying to build audit logging for a website. What I want to do is allow existing MySQL queries to go in unchanged (if possible) to a PHP function which parses the data and stores it in the audit log table.
For example, if I have the query
UPDATE members SET name='Bob', age='40' WHERE memberId=123
then I'd like to be able to pull out the table name members, the rowId 123 and both column/data (as if key/value) pairs name:Bob and age:40.
If possible I'd like a solution which also allows for the alternative query format:
UPDATE members (name,age) VALUES ('Bob','40') WHERE memberId=123
These would then go into an audit log table which would look something like this:
+--------+---------+--------+-----+-----------+-----------+
| user | table | column | row | old_value | new_value |
+--------+---------+--------+-----+-----------+-----------+
| admin | members | name | 123 | Joe | Bob |
+--------+---------+--------+-----+-----------+-----------+
| admin | members | age | 123 | 32 | 40 |
+--------+---------+--------+-----+-----------+-----------+
Obviously to populate this table you can see why I need to extract the values. Ideally I'd like to do it from existing MySQL query strings, passed into my PHP function (to handle existing code), but if I need to implement new PHP functions I'm open to suggestions.
Regex seems both complicated and painful since I'd have to format it for each column name for every table. Is there any parsing solution for this problem out there?
I have one login form and three groups of users who can login: client, member, admin. All users share some common attributes, like username, password, active.
Most of the other fields are different for the respective group, with the table member having up to 30 fields.
This is the reason I would rather not have one large user table with all the needed fields, but separate the group related fields to different tables.
I would then have following tables:
------------------
| tbl_user |
|----------------|
| id |
| username |
| password |
| active |
------------------
------------------
| tbl_client |
|----------------|
| id |
| pid |
| company |
| address |
| projects |
| ... |
------------------
... same with tbl_member and tbl_admin.
But after the login, how can I select the additional fields from either tbl_client, tbl_member and tbl_admin?
I could use a group field in tbl_user and use the group table name as the value. But that doesn't seem very professional ;)
Any other ideas?
I don't know why you say "it doesn't seem professional". You're separating the user data role from the user authentication information as you should. There's nothing wrong with what you suggested and I would recommend it...
I would suggest adding another column in tbl_user that states what type of account it is. e.g. admin, member, client, that way you can direct them to whatever you need after they have logged in, and you can pull their information.
You could do an outter join on all three tables.
This will return results of all three tables, two of which will have null results (as they don't exist). This is less efficient as you are joining four tables (user, member, client, admin), then adding an additional field to specificy which group the member is a part of, and querying only that table with some logic.
What you suggested is a perfectly acceptable solution - tbl_user needs to identify the user type in some way, somehow. You could swap out the string for an id, if that may be easier to work with. After you determine the user type, you can then simply join with whichever detail table is applicable, or query the detail table directly.
Firstly I think this question can be related to any language, but I specified what I was using.
Excuse me if I start to bore also, but I am trying to find out the best way to build a dynamic survey management system.
My client basically has said to me that the data has to be stored in MS SQL as his client has only got MS SQL connector for SAS, which is going to do reporting.
My logic so far is this:
1st. Setup the survey itself, i.e. ask for title, quick overview, etc, etc.
2nd. Define your questions.
3rd. Publish survey.
Now what I have done so far is that when they "publish survey", I have created a dedicated database table for this survey which will house the responses.
From the admin side of this, they will not be able to modify the questions, maybe the question title but that is about it. They cant add/remove questions.
Question is, is creating individual database tables a good thing? My only worry really is that say the admin creates like 30 questions, I will have 30 columns in that dedicated table. To go with that, this way might be easy for the SAS system to pull in data for reporting. The administrator will not see the survey responses in the admin panel btw.
I have done something similar for a language grading exam. I opted for a more flexible approach with the following tables
+------+ +-------------+ +-------------+ +-------------+ +----------+
| Exam | | Question | | Choice | | Answer | | User |
+------+ +-------------+ +-------------+ +-------------+ +----------+
| id | | id | | id | | id | | id |
| name | | questionNb | | choice | | user_id | | name |
+------+ | question | | question_id | | exam_id | | email |
| exam_id | | isAnswer | | question_id | | password |
+-------------+ +-------------+ | choice_id | +----------+
| isGood |
+-------------+
This model allowed me to easilly have a 15 questions exam, a 30 questions exam and a 50 questions exam. To adapt this model for survey, you might just have to remove the isAnswer and isGood part and you should be good and replace users data with anonymous general data like age, income, sex.
Creating a column for each question is totally wrong, altering the database at runtime for business oriented purpose is a "never ever do".
Read something about "relational databases" things should look like this:
table_surveys
id
survey_name
table_questions
id
fk_survey (foreign key to table_surveys)
question_text
(question value? maybe)
table_questions_options
id
question_id(foreign key to table_questions)
option_value (this can be true/false for a test or a numeric value for a survey)
option_label
table_users
id
username
pass
name
table_answers
id
options_fk (foreign key to table_question_options)
users_fk (foreign key to table_users)
This way everything is linked together (No reusing of options,or questions or stuff into different surveys)
According to the comments in the documentation, MS SQL Support in PHP is iffy at best. Is PHP the only language you are allowed to use for the project? If not, you might want to consider using C#, VB.Net or something more compatible with SQL Server. Otherwise, you could initially store the data in MySQL, and export it to MS SQL Server when you needed to do analysis.
Dont know, if I really understand your question. But I once built such a survey system. And it came out pretty quick and easy with about the following tables (if I remember right):
USER, SURVEYS, QUESTIONS, ANSWERS, [some mapping tables]
The SAS will fetch the data from virtual any table. If everything in one or two tables, it will even be easier.
With all due respect to Kibbee, PHP/MSSQL support is actually VERY good. We do it quite often, and the performance bests PHP/MySQL and matches compiled C#/MSSQL (in our very limited and unscientific testing). This is assuming you're running PHP on a Win machine. Running PHP with a TLS connector to a separate MSSQL box is another ball of wax and can be a pain to configure.
Anyway, we had a similar scenario and went with one table to manage forms (Forms w/ FormID as the primary), another to manage fields/questions (Fields w/FieldID, FieldType such as Y/N, text, select, etc.), and another to "assign" a field to a form (FormFields w/ FormFieldID, FormID, FieldID, parameters in an array for select items, etc.). Then yet another set of tables to deal with the answering of the questions.
I agree with the rest of the group. Make sure to normalize and don't create a separate column for each question. It'll be more work initially, but you'll appreciate it when you simply have to add a few rows to a table instead of re-writing your queries and re-designing your tables.