Good Day,
I'm currently designing database structure for a website of mine. I need community assistance in one aspect only as I never did something similar.
Website will include three types of the payments:
Internal payments (Escrow kind payments). User can send payment to another user.
Deposits. Users add fund to their accounts.
Withdrawal. User can request a withdrawal. Money will be sent to their bank/PayPal account.
Basically, I need some tips to get the best design possible.
Here's what I'm thinking about:
deposits - this table will store info about deposits
deposits_data - this table will store info about deposit transaction (ex. data returned by PayPal IPN)
payments - table to store internal payments
withdrawals - table to store info about withdrawal request
transactions - table to store info about ALL transactions (with ENUM() field called type with following values possible: internal, deposit, withdrawal)
Please note that I have already a table logs to store every user action.
Unfortunately, I feel that my design approch is not the best possible in this aspect. Can you share some ideas/tips?
PS. Can I use a name "escrow" for internal payments or should I choose different name?
Edit
DEPOSITS, PAYMENTS and WITHDRAWALS tables store specific transaction details. TRANSACTIONS table stores only limited info - it's a kind of logs table - with a details field (which contains a text to display in user log section, ex: "User 1 sent you a payment for something")/
Of course I have users tables, etc.
Can I use a name "escrow" for internal
payments or should I choose different
name?
Escrow has a specfic financial/legal meaning, which is different from how you seem to mean it: "a written agreement (or property or money) delivered to a third party or put in trust by one party to a contract to be returned after fulfillment of some condition" (source)
So choosing a different name seems like a good idea.
As for design, what data will DEPOSITS, PAYMENTS and WITHDRAWALS store which TRANSACTIONS won't? Also, you need an ACCOUNTS table. Or are you planning to just use your existing USERS table (I presume you have such a thing)? You probably ought to have something for external parties, even if you only intend to support PayPal for the time being.
Related
I am currently learning how to design accounting databases for payment systems like PayPal or PayTim etc. In one of my project I just can't figure how and where to apply double-entry patterns as I learned it is very important in accounting.
So my project is intended to work like PayPal for learning purposes. I created some tables such as:
payments_table - Which store every payment the user pays for service or sending to somebody (Stores money that circulates within the system).
transfers_in_table - Stores every transaction from Visa/MasterCard (Records money that is coming in the system)
withdrawals_table - This stores every money that user withdrawals. (Stores money which going out of the system)
transfers_out_table - Stores money that has been successfully withdrawn by the user.
So when the user1 pays somebody or for service(lets say user2) the flow will be like
User1->Visa->My Project -> User2->Some Fees->Bank.
How do I implement double entry for the situation like this, not to forget I need to store withdrawing fees in database too so that every calculation will balance?
I was thinking of having another table ledger but I dont think if is good solution.
Tables summary
payments_table - id,amount, and userId(FK)
transfers_in_table - id,amount and paymentId(FK)
withdrawals_table - id,amount and userId(FK)
transfers_out_table - id,amount and withdrawalId(FK)
I looked over some of the other answers here and they did not answer the question I have.
How would I go about this problem. If an invoice is created with the following database schema:
id
customer_id
invoice_date
status
the invoice is created, paid etc. If the customer information changes, the invoice information will change since its a FK. How would I create the invoice table to record customers information at that give moment in time, so if the customer change their address in the future for example the past invoices will stay the same with the previous address.
Just wanted to see if it makes sense to copy customer information into the invoice table with their address etc. but then it will adhere to normalizing the database.
Please let me know what your thoughts are in regards to this challenge. Invoices in one example, this can also apply to Purchase orders that were created in the past should have definite information that was recorded in the past no matter what has changed now.
There are different considerations for an order management system or a reporting system.
Within an application, data duplication may prove cumbersome at volume. Will prove cumbersome at high enough volume. So you'll want to be as normalized as possible in that environment.
For reporting and history, though, it would be preferable (maybe mandatory depending on your industry and locale) to have the address info for each invoice.
It would be better to have an address table that joins to your customer table. The addresses would each have their own id field, and then you could just reference that id in the invoice table, too. Probably both the billing address and the shipping address if they're both in play in your business model.
If you don't have the flexibility to introduce a stand alone address table, then copying the address information over to the invoice table becomes a necessary evil. But dead useful information to have.
I have a requirement where I need to create A database where a user can have multiple payment methods and against those multiple payment methods multiple transactions can be processed.
I have created the following schema
WHY THESE TABLES:
user: This table contains information about the user. Ex: First Name, Last Name, Email etc
user_payment_method: Since a single user can have multiple payment methods I created a table to identify all the payment methods he has so that i can reference them in the transactions table and could know on exactly which payment method the transaction was made on.
transaction: This table contains all the data about all the transactions. Ex: Time, user_id, user_method_id, amount etc
payment_method: This table acts as a junction table(pivot table) to reference all the payment methods that could exist. Since all payment methods have different details I cannot make a single table for this.
specific payment method tables: Tables like bank_transfer and paypal contain the specific details the user has about that payment method. Ex: paypal keys or bank account numbers
THE PROBLEM
I am stuck at creating a relationship between payment_method and specific payment method tables.
How do I reference different payment methods within a single column in the payment_method table. Do i create a junction(pivot) table for each specific payment method?
EDIT: If anyone has a simpler different approach please let me know too I am open to all ideas.
I would probably simplify the schema as follows:
user <- transaction -> payment method
The payment method would include your PayPal and Bank Transfer, which should not be different tables.
Generally, you should think of your payment method as a type of transaction.
When constructing a database, you look for the tables where the real action is. In this case it’s the transaction table. You can recognise it from an entity diagram as the one with the foreign keys pointing outward. In this case, you can say that a transaction belongs to a user and is of a certain type.
The transaction table would have the actual payment details, such as the date, amount, transaction number etc.
You could also have a table of preferred payment details. That would give you something like this:
user <- transaction -> payment method
<- preferred ->
Remember, that preferences can change, so the data from the preferred table should be copied into the transaction table, to allow the preferences to change later.
Needless to say, we presume that you are taking all the proper precautions regarding passwords, account details and other sensitive data …
The problem can be categorised as modelling inheritance. You have n payment methods, each with different (user specific) properties. The simplest is TPH table per hierarchy: put all the user properties for all payment methods on the user_payment_method table. There are other options covered here. Forget about pivot table: you're modelling a DB schema and you only need tables and columns. Think about what you need to store, how you need to retrieve it, and the importance of storing each fact once only.
I'm a bit of a newbie with databases and database design, but I'm hoping someone can point me in the right direction. I currently have 14 monthly loan extracts, each of which contain all accounts, their status, balance and customer contact info as-of month end. Not knowing what to do, I imported each of the monthly files into Access with each table acting more like a tab from an Excel workbook. Laugh away - I now know that's not how it's supposed to work.
I've done my homework and I understand how to split up part of my data into Customer and Account tables, but what do I do with the account balances? My thought is to create a Balances table, create a relationship to the Accounts table and create columns for each month. This seems logical, but is it the best way?
99% of my analysis involves trend reporting and other ad hoc tasks - tracking the total balances by product type over time given other criteria, such as credit score or age. My intended use is to create queries to select the data I need and connect to it via Get & Transform in Excel for final manipulation and report writing.
This also begs the question "how normalized should my new database be?" Each monthly extract is cumulative, so a good 75% of my data is redundant contact info already, but how normalized should I go?
Sorry for ranting,but if anyone has any experience in setting up their own historical database or could point me in a direction that will get me on track, I would appreciate it.
Best practice for transactional systems is close to what you expect:
1. Create a Customer table
2. Create an Account table
3. Create an Account Balance table
4. Create relationships from the Account to Customer, and from the Account Balance to the Account table.
You can create a column for each month, provided you have Year as part of the key of the Account Balance table. Even better would be to have the key for the Account Balance be Account ID and Date.
However, since you are performing analytics over the data, a de-normalized approach is not only acceptable -- it is preferable. So yes, you can (and perhaps should, based upon your use cases) put all the data into one big flat table and then compile your analytics.
For an ecommerce site that allows both Guest checkouts and registered user checkouts, how will you handle the 2 different customer groups?
Do you store both groups in the same table customers which has a foreign key customer_group_id pointing to another table customer_groups? In this case, will you worry about duplicate guest checkouts "polluting" the customers table?
How will the information captured for the 2 customer groups be different? I am thinking the difference is that the guest checkout customers will not have a password thats it.
I store customer information directly in the order rather than rely on the information in the customer record. That does a couple things:
I don't have to have a guest user in the customer database
If my customer information changes, or if a customer wants to ship one item to one place, and another item to another place the information about the order will still be correct.
I view order information as historical data. It should not change because something else in your database changes. For example if I order something from you, and at some later time I move and update my billing and shipping information, you should still know that the previous order was billed and shipped to the previous address. If you rely on the relationship between the customer and the order to retain bill to and ship to information, Once I move and update my profile, you think you shipped to my new address. You may not see that as an issue, but it will be.
You can still get the current information from the customer record to populate the fields on the order if the customer has an account. For a guest, he has to type it every time.
The common entity is a Checkout. The guest checkout would be a null FK link on the checkout entity to a registerd user entity.