Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am developing an application for a small financing company, where they can input payment amount. The date will be generated automatically. My question is, what is the best way to save those payments in MySQL, considering that some loans will be as short as 6 months, while others will be as long as 84 months?
I'm thinking about a table with 169 columns:
REC_ID as primary key,
Date1, Amt1, Date2, Amt2, etc...
But, how efficient would it be? On a 6-month loan, out of those 169 columns, only 13 would be used.
Thanks in advance for your output.
Create a payment table that has a the foreign key of the loan id in it.
the payment table will look something like this
id|loan_id|payment_date|payment_amount
Have a separate table for loans that will look like
id|loan_amount|loan_length
When you need to find out how many payments have been made run a query on the payment table with the loan_id as a search parameter.
This would be a gross violation of relational design paradigms, each payment and Date should probably be a its own tuple in a table with a many to one relation to the accounts table.
Accounts (REC_ID, other_stuff, other_stuff) Primary key(REC_ID);
Payments (REC_ID, timestampe, amt) Primary key (REC_ID, timestampe);
Also consider using foreign keys to enforce existence of a valid loan for each payment. And I would guess the policy would be cascade so that deletion of load and renames of loans would carry through to the Payments table.
Related
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 have a mysql database and some tables.
One table is Products: Its columns are prod_id, prod_type.
Prod_types are mobile or laptop or book.
Each of them have different attributes (eg: publisher, author for books, battery_condition, model for laptop etc).
Should I store all the data in the Products table by adding columns like 'author', 'model' etc and keep null for those columns which don't apply to my product.
For example for an entry with prod_type='book' , 'model', 'batter_condition' etc will be null. Or should I create different tables for 'book', 'mobile' and 'laptop' ?
Yes. Create new tables for Book, Mobile and Laptop. Have the product_id attribute in each of those tables. This product_id attribute is a foreign key to the primary key of table products, which is product_id as well.
Storing all data in products will result in a lot of NULL fields and will make the data storage inefficient.
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 4 years ago.
Improve this question
Hey so i have been doing alot of reading and i am finding many conflicting ways to link my tables. hoping someone can help me put the foreign keys in the correct places.
tables -
customers: customer_id(primary), customer_name ;
employee: employee_id(primary), employee_name ;
appointments: appointment_id(primary), appointment_date ;
inventory: inventory_id(primary), item ;
so i have primary key for each table but i need to link 1 customer to the appointments table and multiple employees to the appointments tables.
the inventory table must link to the appointments tables.
Here is an example, customer sets an appointment then employee(s) fills appointment. during that appointment the customer buys an item(s).
it is sufficent enough to just show the item with the appointment. the item does not need to link to the customer.
thank you for help. i was thinking i needed to make a 5th table to fill with all the keys but im really unsure and the tables have alot more information in them than i posted above. would be alot of trial an error to then see if not work one of the ways i need.
You should add customer_id foreign key to the appointments table
You should create table appointment _employee:id (primary key),appointment_id(foreign key), employee_id(foreign key)
You should create table appointment_inventory:appointment_id, inventory_id
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 5 years ago.
Improve this question
I’m currently trying to design my table structures for a made up database. The database will have three separate tables and track the populations of cities for 10 years. After every year, population figures will be added for each city in the database. Here is how I’ve laid out my three tables so far:
Cities (city_id, city_name, city_abbrv)
Year (year_id, year)
Stats (year_id, city_id, population)
I’m worried about not having a unique identifier in my Stats table. With 10 cities, the year data will be the same for 10 entries. Once I enter multiple years of data, the city_id will be reused. In my research on this site I’ve read that having a unique ID for every table is not required but the book I’m using to learn database design (while brief) never mentions that this is okay. I would like to know the best way to design a database that receivers data entries for the same group of things on a daily/weekly/monthly/yearly schedule. Should I add in a unique_id column to my Stats table? Or would this be a wasted column? Thanks for the help!
First of all you need each of those tables to have the column id as primary key.
A primary key is used to uniquely identify a table row. A primary key cannot be NULL since NULL is not a value. So basically those columns will be unique yes.
Question: Why you need primary keys in your tables?
Answer:
If you are looking to select data from different tables you are opting for join so you need keys to use for that join.
If you want your
table to be clustered, you need some kind of a primary key.
Side Note: You may need to get familiar with indexing columns, see advantages of indexing.
Cities (id, city_name, city_abbrv) //with id as primary key
Year (id, year) //with id as primary key
Stats (id, year_id, city_id, population) //with id as primary key
//And year_id and city_id as foregin key connected by their respective ids
If you are still beginner with MYSQL see the W3school tutorial for SQL primary keys.
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 am currently working on a private chat between two users using NodeJS, AngularJS, MySQL and Socket.IO. I want to somehow save the chats so that you don't only see the new chat you are writing that gets transmitted via Socket.IO but also the messages you have written before your current sessions.
How do I properly store these previous chats on my server?
The usual way to do this is :
Table messages:
message_id PRIMARY KEY
sender_id FOREIGN KEY
recipient_id FOREIGN KEY
Index on (sender_id, recipient_id, message_id)
Index on (recipient_id, sender_id, message_id)
However, this structure has a problem: there is no easy way to efficiently sort the last N messages by "id DESC" because you'll have something in your WHERE like "WHERE sender_id=... OR recipient_id=..." and this will make the last two indexes (which are intended for fast sorting) kinda useless.
A smarter structure is thus:
Table chatrooms:
chatroom_id PRIMARY KEY
Table chatrooms_users
chatroom_id FOREIGN KEY
user_id FOREIGN KEY
Now, when two users (or more) want to start chatting together, you either create or reuse a chatroom from said table, and insert the relevant lines into chatroom_users to link the chatroom to its active members. This should be updated as users join/leave the chatroom.
If conversations only involve two users (and never more than two) then you can use a simpler structure:
Table conversations
conversation_id PK
first_user_id FOREIGN KEY
second_user_id FOREIGN KEY
Anyway. The whole idea is to give a unique identifier to a thread of conversations between our two users, or to a chatroom. Then, the messages table becomes a lot simpler:
Table messages:
message_id PK
chatroom_id (or conversation_id) FK
sender_id FK
Index on (chatroom_id, message_id)
In this case, note that the last index optimizes this:
SELECT * FROM messages WHERE chatroom_id=constant ORDER BY id DESC LIMIT 10
Thus, when the user opens the chat window with another user, you can find the conversation_id (or chatroom_id) easily, with an index lookup, and list the last messages quickly, also using an index lookup, and without any sort.
Old messages should be pruned and moved to an archive table, to keep the messages table small and cachable in RAM.
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 2 years ago.
Improve this question
I am thinking of creating a "wishlist". Each user will be able to purchase wishes in a shop. How do I store the wishlist? I am thinking of creating an user table and a wishlist table.
The structure of user table:
Columns: id, username, password etc
Columns: id, wish, price, quantity etc
user id is the primary key for user table and its a foreign key in wishlist table. However, when I come to think of it, my wishlist table will have duplicate items for each user, won't it?
Is there a better way to store the wishlist things?
I am using mysql. Thanks
You should also have another table to store the purchases:
Purchases
Id
UserId
WishId
PurchaseDate
Users
Id
Name
Password
Wishes
Id
Wish
Price
Quantity
Every time a user purchases a wish, you create a record in the Purchases table, and decrement the Quantity count for that wish.
It is a 1 to n relationship.
Asuming you have a User table with a user_id as primary key then
create a table Wish which has user_id as foreign key.
Add the attributes you want to this second table and violá.
Luis
You should have another table for wishes (wish id, price, description etc), and you should have a joining table (user id, wish id, quantity, quoted price etc). This table will allow you to have a many-to-many relationship between users and wishes.
(Further to my comment... see? You have two different suggestions already. Ultimately you have to decide what is best, and ideally your business/project requirements should guide you.)
EDIT: make that three different suggestions
You essentially need to know just a few things to add information to a wishlist. Here's how I have it in one of my client projects:
Wishlist
wishlist_id
user_id
product_id
created_date_time
It would make sense to have wishlists only for authenticated users, so ensure that you are taking care of that.