I'm building an API in Laravel.
Here's my system:
In the system there are performances, it's dates and it's prices. So, 3 tables.
An user can buy tickets to performances. So, another table.
An user has to be able to buy at once several tickets of different prices. One more table, Transaction.
What i have right now is an API that accept POST's with the following payloads:
performance_price_id, performance_id, performance_date_id
So it only accept one ticket per Transaction.
Problem: how to adapt this API to accept several performance_price_id's, so that an user can buy for example 5 VIP tickets and 5 normal tickets in a single Transaction(to the same performance at the same date, of course).
Note: there is not a static number of prices per performance.
Solved it by using a string with the next format:
performance_price_id,performance_date_id;performance_price_id,performance_date_id;...
And instead of having undefined number of payload arguments, i have a well-defined number (2), which are
performance_id and tickets
Related
I needed to advise about the woocommerce plug-in invoice, do you know any way of doing this if we have more languages on the site, such as EN, PL, CZ, HUN, so for each language we need separate invoice numbering. That means if the EN buyer purchases the product, then the invoice number starts 20190001 and if another client comes from the PL and purchases the product so that his invoice is again 20190001 because it is from another country? And so for all countries, each has a separate number of invoices.
Thanks for helping
A large part of the value of having an invoice number is that it uniquely identifies a transaction. If you implement your strategy, you will always need two pieces of information to identify the invoice, specifically the invoice number and the language code. If the language code is a business requirement, I would suggest you use a smart number format. A smart number is a unique identifier that communicates additional information about the entity identified. For example, in your case, the first invoice could be EN001, the second invoice PL002. The first two characters are a language code. The second three characters are a sequential number, and you know by looking at the second three characters that this was the n-th invoice created.
A disadvantage of using sequential numbers is that you expose some information about the volume of your business. This is sometimes illustrated as the "German Tank Problem", based on the story of how the Allies in World War 2 used the serial numbers found on captured / destroyed German tanks to estimate manufacturing capabilities, and subsequently the number of tanks the Germans had. More info: https://en.wikipedia.org/wiki/German_tank_problem
You could use a series of number for each language code, such as EN001 and PL001, but you would decrease the amount of information coded in the invoice number, and you would have a harder implementation in WooCommerce since you would need to maintain index numbers for all languages in order to create the unique invoice number for each invoice.
I am working on a project, and I am trying to find a way to associate my pricing plans table with a customer.
id name description price days
1 Free the free plan 0.00 0
2 Silver the silver plan 49.99 365
3 Gold the gold plan 99.99 365
My first thought was to add the plan id as foreign key to the customers table. But i also need to know when is the expire date (based on the purchase date and the days of the plan selected).
When attempting to do something like this, it is best to keep tables abstracted from each other.
user_pricing_plans - the table name
pricing_plans_id - the id for the record you want to associate with a user
user_id - the id of the user
date_expiration - the date the plan will expire
date_purchased - the date the plan was purchased
following an approach like this will allow you alter this table if needed to add extra information. you could also follow a similar approach in the future with another table.
the key to all of this is separating your concerns ( the data ) into separate containers.
Edit: to kind of hint at what I'm getting at about why separating the tables is a good idea, I added the date_purchased as a field in the user_pricing_plans table.
a dba I know once said that "mysql is not a place for developers - they try to create tables to work with their code. tables are meant to represent data. your code should be written to work with the data and the schemas that represent them - not the other way around"
I do not know why I can not add a comment to the best answer in the post.
As #Jonathon Hibbard points few years ago, there is another reason to separate the data between pricing plan and user model.
You used to have users who have one plan and choose another later, that is called, "history". To manage that, this third table is very important.
And in my opinion, more important, one thing is your pricing table, an another one is the final price you have with every client. Yo have knownledge people, close clients that you want "special" prices, this third table gives you the oportunity to set diferent prices for one plan with fixed price and a lot of other use cases.
Think about your main plan table like a product, the user is the client, and the third party as the ticket, with "temp pricing" aplied, ocassional discounts or whatever.
In my website, I allow groups of users to manage a group bank account. Users report that they payed for something the group should fund, and the group account 'pays them back'.
However, I want to give the account admin control over which user pays what and when.
For example, a group of people share a car. They open a group account to handle their car-related expenses - gas, maintenance etc.
The group admin decides that only people who drove over 20 miles this month should participate in the gas bill, and the bill is divided between the paying users (those who drove over 20 miles) proportional to their mileage (a user who drove 60 miles will pay twice as much as a user who drove 30 miles).
I have a table for users (a list of users, each one is part of a group account), one for group_accounts and one for expense_types (in this example, gas and maintenance are listed here)
The question:
Is there a good way to store client-defined queries or algorithms in a database to allow the admin of the group to create complex billing methods, and (using PHP) subsequently retrieving and implementing those algorithms and calculating the result?
This is a database design question, so as far as I'm concerned extra columns may be added to any table, new tables created, procedures, triggers etc.
NOTE: THE SPECIFIC EXAMPLE IS OF NO REAL INTEREST, I want my system to handle algorithms of unknown complexity that use data from unknown tables and columns.
I am designing an online accounting system as a college project. I have got the following simple transactions.
Sales on cash $300
Cash burrowed from Smith $250
Electricity bill paid $50
I have referred Double Entry Accounting in a Relational Database and designed the above Transaction table(minus sign means the amount is credited). The id 1 and 2 belong to transaction 1, id 3 and 4 belong to transaction 2 and so on. How can I identify each two rows as a single transaction in MySQL database.For example if the first transaction to be selected how can I do it since there is no relationship between the two rows. If this design does not sound good can you suggest an alternative.
You should drop the two line design unless it's really necessary. I would merge the rows and add an extra field where you could store if it was cash or not and the amount value would be + when credited and - if debited (or reversed, I"m not good at accounting :))
Good Job.
The only thing I might add is two number columns for debit and credit. That would look just like a journal in the text books or old bookkeeping books. It would be a little more visibly obvious and handle any number of double entries. Your current amount column could be calculated by debit - credit if you like.
I do not think you need to make it relational unless you wanted a specific chart of accounts as a table, more complicated and less elegant. But, for more flexibly you could generate real time chart of accounts from the journal.
Since you are using MySQL relational database, you can add several tables.
To answer your question, you need to create another table to hold general information for each transaction (e.g. you could call it a TRANSACTIONS). This table could include Transaction ID, and Date Column.
Now, reference the Transaction ID column of the TRANSACTIONS table in your currently existing table. This means record 1 and 2 will have one Transaction ID and so you can reference it as such in your queries.
I'm actually worried about designing the perfect tables to handle transactions and commissions. especially that we really don't want tables to be out of sync in any case.
Basically this is like ebay, where merchants sell to buyers and we get a commission out of each transaction.
The app is already built using Codeigniter, and it has:
Merchants(id,name,balance)
Transactions(id,merchant_id,buyer_id,amount,transaction_id)
Now what other tables to make if needed to make us able to fetch our revenue and the seller's revenue, and what's the best DB mechanism to process a refund?
And should we make another table of each deposit to the merchant's balance rather than +x the balance row.
Whenever you are dealing with any financial tasks, always store as much information about it as possible.
There are two ways of keeping all your tables in sync.
Database level - using options such as stored procedures and triggers
Application level - Use transactions (innoDB) and make sure that the transactions are atomic. (I would suggest to go with this)
Regarding the database design -
Add a column commission to Transactions that tracks your commission. Data for this can be either calculate beforehand when pricing the item or on the fly during the transaction.
The buyer pays product cost + commission, seller gets product cost and you get commission. If your commission is a variable (not a flat rate and changes from item to item), you could have a column in the Items table which stores it. Things should be trivial from now on. You just have to maintain a History table that keeps a list of transactions with respect to the user. It would look something like
AccountHistory(id, transaction_type, transaction_id, amount)
You could split AccountHistory into two - one for incoming money and one for outgoing money.
So everytime a transaction takes place the following happens
Entry into to Transactions table.
Entry into AccountHistory for buyer
Update buyer balance
Entry into AccountHistory for seller
Update seller balance
All this should be atomic.
For rollbacks, you could add a column transaction_type to distinguish rollbacks from normal transaction or you could maintain a separate table.
Having worked with a database where the design had financial transactions scattered around a bunch of different tables, I can tell you that it is much better to have all transactions in a single table. You should add transaction type to your transaction table (and a look up table for the transaction types).
Then each transaction can have a separate line for commission and seller product cost. Transaction that are undone later would get entered in as negative amounts. It is also helpful for these types of things to add a parent transaction field so that you can easily identify which transaction it was changing.
All data entry that forms part of a transaction should be in a stored proc and have transactions so that if one part of the insert fails, the entire thing is immediately rolled back. This is critical. It needs to be in a stored proc so that no one (except systems dbas) has direct access to tables that store financial records.
When you start to think of handling financial transactions the very worst thing you can do is design for the user interface alone. You need to design for the financial reporting you will need to have. You need to consult the people who will be auditing your finances to see what information they need and what internal controls they expect you to have in place to prevent internal as well as external fraud.