Best practice for setting a selected row in a database [closed] - mysql

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have one table called addresses in my database which stores all the shipping addresses which belong to the user. A user can select their primary address.
My question is, which is better practice:
To create a separate table for the primary address selection (e.g. a table called primaryaddress with a user_id and address_id foreign keys. If a row exists in this table, it links to the primary address of the user)?
or
To create a value in the addressses table which keeps track of the primary address (a boolean called primary which can either be true or false)?

Personally I would add an AddressType field on the Address table and make a unique constraint against the UserId and the address type so that the user can have many addresses but only one of each type i.e Primary, Secondary, Other etc.
This lets you have the option to have other address types in the future and doesnt lock you down to a boolean flag. Then if you decide a user can have many primary addresses you can remove the constraint and implement logic to handle this.

Related

Joining tables that don't have a common id [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have two tables in a MySQL database. One is "accounts" and one is "posts". I'm at the point where I want to allow users to only edit their posts, which I think means I need to create a table join. The problem is there isn't a common id for each table.
Accounts:
id, first_name, last_name, username, password, email, activation_code, rememberme, role
Posts:
id, title, body, author, tags, status, image, created_at
I'm still searching on how to do this. I know I need to create a common id. That's where I'm getting confused since there will need to be a common link when a post is created. Can someone point me in the right direction for making this happen please?
The "author" column in Posts table should ideally be a foreign key of the "id" column in Accounts table. This would allow you to join the tables based on this column. A foreign key can be added as follows for your case -
ALTER TABLE Posts ADD FOREIGN KEY (author) REFERENCES Accounts(id);
You can have a look at a tutorial about foreign keys here - https://www.w3schools.com/sql/sql_foreignkey.asp

About UUID data type as Primary key [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
By using UUID as a primary key in a table we can protect our data from attackers, But we also store the user ID kind of details in the table. If the hacker gets to know the User ID he can get to know details about the row. So, What's the use of UUID here?
UUID is basically there for uniquely identify records in the table. There's nothing related to security. What you need prevent is SQL injection attacks from happenning to your database. For that you can use Parameterized stored procedures. Either case once the intruder has access to the database it means either way he will have the access to the table rows.
For internal relations and for referencing, an integer with auto increment is perfect: small size and small index.
I use additionally UUID in some projects to hide data uploaded/set by a user. The user gets a link with UUID and can provide it to any other. Example for a database layout for this case:
dis_id int unsigned not NULL auto_increment,
uuid char(36) not NULL COLLATE latin1_bin,
... and optional ...
unique key(uuid)
Collation latin1_bin optimizes space and search efficiency. You can store an UUID as 16 byte binary data too.

Mysql, retrieve students who haven't received a request from me [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am currently logged in as the first student. I want to retrieve a list of the students I did not send a request to yet. I also want to retrieve a list of students I sent a request to.
Both sender_id and Rec_id are foreign keys referencing to Students.id.
DB schema
Hi Souleiman and welcome to stackoverflow! Your question is not quite clear, you say that sender_id and Rec_id in requestts are both referencing to students, but you can't see to which field exactly. Your requestts table contains different entries in these fields.
Next time you should post the output of SHOW CREATE TABLE students and SHOW CREATE TABLE requestts and a little INSERT statement for the data. Furthermore it would be nice if you would explain the relations and show what you have already tried (see Barmars comment).
I suppose that the relevant foreign key in requestts is Rec_id, so you could try this query:
SELECT s.email FROM students s WHERE s.id NOT IN
(SELECT Rec_id FROM requestts WHERE Rec_id = s.id);
Hope this helps. Have fun learning SQL!

Storing user data (settings) in separate table to speed up user search [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
If a web application has to search many IDs to find a matching on, but doesn't need any user data until the correct one has been found, would it be optimal to store the user data fields in a separate table and use the Accounts table (which contains user ID, password hash, etc.) for searches?
Create a clustered index on your unique ID field which will determine the physical ordering of data and it will speed up the searches and then you can extract only the required rows.
You can also create a non clustered index and then make it point to the primary key.

sql - calendar table [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to create a program where a person will be able to save his schedule.
For example a doctor will be able to save an appointment.
I want to save every appointment in a mysql database. So I need to create a calendar/appointments table. In every appointment I want to save these information:
day
month
year
start (hour)
finish (hour)
participant (the patient)
I was thinking of creating a big table with all the possible appointments for some years (ex. 20 years) and leaving the participant column empty, meaning there is no appointment. If an appointment is made the the participant field will be filled.
Is there a better way of doing it? Can someone provide some guidelines and if possible an example? I want to keep it as simple as possible.
table appointments
--------------------
id int (primary key, auto_increment)
participant_id int (foreign key to persons table)
starts datetime
ends datetime
Then only save the real appointments and not empty ones. Storing fakes is never a good idea.