I am creating an application that users could deposit money on their account and trasfer to other users. I am wondering if Markle Tree is the ideal solution for SQL transaction for money transfer. I've read this article, and came with the idea of implementing this kind of "security" in my app for preventing someone to change some values.
So, how could be the best solution to implement on my database model, does anyone could help me? For now, my database look like this:
The main idea is to create a transaction since there is a payment, and the transaction only occour if the sum of the value of all transactions of the user is equal to the amount in his account. Is that a good way, or could be better?
I don't really understand what you want to achieve. I understand that you want to sell something on the internet and you are creating a database for it. If you want to sell a subscription, the more important issue is the validity of the purchased service (date from-to). Take a look at the model below.
Database model for transaction-subscription:
Related
I'm designing a database for a SaaS. As a rough explanation I can say that we will have:
Account (our clients)
Client (our clients clients)
Appointment (appointments made by some client or by some person that hasn't a client account yet)
Analysing this use case I came up with a redundancy database dependency. I want your help to understand if this is the best way to do it and if you have some suggestions on this design.
Questions:
Do you think this type of dependency is the best way to solve this use case? If not, how do you do it?
In legal wise do you think I should have a different database for tenant? I want to make an MVP (startup wise) to test and put the business running, so I'm having serious doubts if I should address this from the start, but I want to have a clear roadmap.
First of all, you don't have any circular dependency in your database design (data model).
Definition: (from wikipedia) a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly.
Second: your data model has Redundancy. There is no need to relationship between Account and Appointment.
if each CLIENT related to only one ACCOUNT, so each APPOINTMENT of each CLIENT is related to one ACCOUNT too. The relationship between APPOINTMENT and ACCOUNT can be reached from relationship of CLIENT and ACCOUNT.
Finally: for your second question, having other databases for tenants, the answer is related to many parameters like your project size, number of clients and etc.
Currently have a ~2GB CRM database that's built on mysql + cold fusion and running on our local MS2012 server. Looking to move it to a more usable/up-to-date solution that would allow flexibility, security, and back-up solutions. Also no longer going to be running on cold fusion.
I received the full backup database in a .bak and have restored successfully in Microsoft SQL Server Management Studio so I see the massive list of tables, views, programmability, service broker, storage, security.
Salesforce seems to be a good bet, as we would likely be able to hire someone in the event that I leave so someone could pick it back up and work with it. Also, Salesforce makes sense in what we're trying to do with the CRM.
I'm unsure about how to do this migration. Right now I'm working on a backup copy to practice and put a process in place to ensure we have a smooth transition because the company is still doing their day to day on CF until we have a set in stone stop date to do the transfer. It'll be a one-time transfer so I don't need to establish a constant connection, I just want to pull in all the database tables, values, relationships, etc and then get everyone setup. I realize pulling in users with login information might not be feasible and I would have to create users in salesforce. I do want to have the data that each user has put in retained though.
There might be some additional data you guys need to fully answer the question so please let me know if I have some crucial gaps that would help get the proper answer.
DBAmp is pretty much industry standard at this point. https://appexchange.salesforce.com/listingDetail?listingId=a0N300000016bWzEAI. It will allow you to do CRUD from SQL.
Also, when you sign an agreement with Salesforce, they will also hook you up with an integration partner to whom you will pay large sums of money to help you with the transition.
Edit: Sorry, I guess I didn't really answer your full question. Yes, you are missing large, LARGE pieces of information. DBAmp will help you with your data, but don't think you will just be able to import your data structure over.
I'm trying to create a payment system for my website. The website is a market place for 3d printing blueprint. Users buy credits on my website. When a user purchase a 3d printing blueprint uploaded by other user, it creates a new tuple or a row in the 'purchased' table while deducting credit in user credit table. Here's the important part. My gut tells me to use event scheduler to mark rows of purchased as payed every month and wire the sum of money earned by each seller. My worry is the table will grow infinitely as months pass by.
Is this the right implementation?
Or can I somehow create a new table each month that holds transactions for only this month?
Is there a Nosql equivalent to this?
Stripe.com or Braintree.com might be good options for you.
It is not advisable to create or roll your own payments implementation. These established services not only handle the PCI compliance aspect of payments, but they also have direct support for the use case you're asking about.
In an effort to answer your question further - it's probably not going to be an issue from the stand point of performing inserts into this MySQL table or in terms of iterating across it for batch processing. Querying on the other hand will become more onerous as the data set gets very large.
You can use partitioning in MySQL and perform the partitioning based on date but I doubt this is something you should spend your time accomplishing at this point. Wait until your site blows up and is super popular then come back and update your schema and configuration to meet your actual usage demands.
It's worth noting that you'll also want to make sure to take regular backups of something as important of payments information. Typically you'd also see at least one replica for something this critical.
Again I don't think you should try and solve this yourself. Just pay for a service that does this for you and focus on building the best 3d blueprint marketplace.
I'm building up an online (paid) service used for business administration purposes. The database is structured like so:
I have a contacts table filled with persons, contact info and the like. Then I have a few other tables holding information about payments, agreements and appointments. Also statistics like how much money was transferred this month, how many hours worth of appointments this month and the like.
I'm using MySQL (but could also go for MSSQL or some other service if necessary) and I had no formal training in any programming language whatsoever (yet).
I'm building a WPF application for acces to this database. Also planning on building an app so users can access their data and plan new appointments and register payments on the go.
I'm going to go for a login system to verify their right to login and use my service.
My question is about how to structure this. I'm not an SQL expert nor have I had any formal training in SQL or any other programming language. What I do know though is that my client-side app is almost out of the alpha stage.
So far I have come up with two ways to structure this.
1. Users get a seperate database.
My original idea was to give each user a seperate database, this makes it easier to provide people with statistics. Also it makes it easier to spread the workload through multiple, seperate servers. People would login to a master/main server, where their login information is stored, fetch their server info and programatically be 'redirected' to their own database. Spreading these databases also make it easier to provide individual back-ups to users.
The down-side of this is the sheer quantity of databases I'd have to manage. I'm planning on ending up with hundreds of thousands of users. Let's just say I want the system to be able to provide to an infinite amount of users.
2. Everything is stored in one database.
It's also possible to store everything in one database. This would make the database structure somewhat more complicated (while it also makes the whole a lot simpler). I'd have to add 'AND consumer_ID='" + MyID + "' to every query. (Which ofcourse is possible) and add a few tables to handle statistics per user.
It would be simpler to provide every user with the same database updates. Maintenance would be easier.
The down-side of this is that it makes it harder to spread the workload to seperate servers, I'd have to build something to make it possible that seperate servers mirror each other. Also I'd have to make sure that the workload is automatically divided between the servers, instead of simply going for: Fill server with X databases, then new server, fill, new etc.
I'm not in the luxury of hiring someone with any SQL training.
The most important thing for me now is that the system can be easily maintained while still being safe and reliable. I'm an amateur developer, going to college next year. I don't want to spend 50% of my time maintaining the database.
I think I got the major part of the details you might need, if you need anymore please ask for them.
I thank you in advance :)
Just go with solution 2. The downside of spreading the workload to many servers is fullfilled by "partitioning", look here for a starting point: http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
Partitioning would allow you for example to put all information of a table containing even IDs for consumers on the one, all other on the second server. Or whatever you want...
But i wouldn't start that complicated: do you need that now? It burdens you (either way) with such a big additional overhead! You can also look into the NoSQL database world for solutions that can be spread to as many servers as you want with low effort. You loose SQL and it's ACID features in the most cases; if you need those NoSQL is not an option.
I'm building an e-commerce app for an online store, and I'm planning to have a credit system so customers can earn credits to purchase products.
Handling credits I have no problems with, but I'm uneasy about the idea of storing values with actual monetary value in my MySQL database.
Currently I'm planning to have a table for Credits with a foreign key that links it to a user, so I can figure out a user's amount of Credits by a single JOIN.
I just wanted to ask if there are things that I should be careful with, lest I leave vulnerabilities that could be avoided.
Thanks!
First, as Fernando mentions in the comments, use decimal to store the value.
Have audit trails, that way you can go back and determine why a value is the value it is.
Your biggest challenge will be making sure your system is secure, not so much how it is stored (although that obviously comes into security as well). Make sure the app is tested, perhaps with a proper pen testing tool to start with. Make sure the product machine is locked down and audited.
It (almost) goes without saying that reliable and tested backups are extremely important when dealing with something of value.
I'm also assuming that you are not handling credit card transactions directly? Just in case you are, I urge you to reconsider and use a third party because there is a lot that can go wrong for you (or your customers). Plus, you don't want to have to deal with PCI-DSS.