Okay..
I am making a web base application,that will be connected to a sms gateway.
It is basically an attendance app for colleges.
The Attendance will be updated using a sms by the teacher.
Now,the main part-
What I want to do is,the teacher should not be able to correct the attendance after 10minutes of sending the 1st message.i.e,the database should accept a correction or new message for the same class and the same teacher only for 10 minutes after the 1st attendance is recieved in the database.
So only recieving from a particular number should be blocked and also only if it is for the same class...
I hope the question is clear :o
Thankyou
This is not the sort of thing that you should be enforcing at the DB level, it belongs in your application code. If you can't connect time, number & class together in your DB, it's time to change your schema.
As Sean McSomething mentioned, this is not done at database level, this is business logic that should be checked just before interacting with a database. The best practice actually is to simply add a column time_created and before updating simply check if NOW() and time_created interval is less than 10 minutes. It's a pretty trivial job, but don't bother trying to do this in database with some stored procedures or other stuff, as it will make your application almost un-debuggable and very sloppy.
Check if there is a row with active number and active class, if there are no - insert, if there are any - check if this row's time_created is greater than 10 minutes ago, if it's not - update, ignore otherwise.
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 7 years ago.
Improve this question
I'm going to be launching a site soon and I'm using a MySQL database to store data. I want to make sure I'm not forgetting to save anything that could be useful later. I currently have two tables, users and events. users is just the registered users of the site, and events are events that users can create on a schedule. Here's what I store for each table:
users: id (int(11)), email (varchar(75)), password (varchar(10000)), first (varchar(35)), last (varchar(35)), reg_date (timestamp), (a few other things)
events: id (int(11)), description (text), day (int(11)), month (int(11)), year (int(11)), hour (int(11)), minute (int(11)), creator (int(11))
Do you guys think I should add anything? Any suggestions in general for my tables? I'm pretty new to MySQL.
Edit: I'm also adding a created row to my events table with the date the table was created. I'm also probably going to add a edited row where I will put the old description should the user edit the event (not sure though).
You have covered all the basics, other itmes commonly included in user tables;
Username, or preferred display name
Gender, which can also be inferred from Title (Mr, Mrs, Miss, etc)
Address, people tend to overcomplicate this, unless you really need to know street names, zip codes, etc explicitly just save the whole thing into a text/blob field which can be used for mail outs, etc
Contact Phone/Mobile
Important Security Fields,
Iam not sure why you need 1,000 character passwords, I suspect you may not be hashing, this is not good, please hash!
Consider adding an additional 'salt' column, using unique salts significantly improves password security
Track failed login attempts since last successful login
Information you can gather automatically, which may help with marketing
Last login IP - can be used to determine users geolocation
Login count, how active is this user
Last login date, useful for security and identifying stale accounts, but also makes it easy to see how many logins you have had in the past day, week, etc
Let's get this out of the way right now, DO NOT STORE THE PASSWORD! This is how passwords get stolen. Only store a properly salted hash of the password. Use either the built in SHA2 or, better yet, bcrypt.
Read all about how to do it right here.
Some notes about types.
Don't use TIMESTAMP, use DATETIME. TIMESTAMP is quirky and has a limited range of 1970 to 2038.
Store the date in the events table as a single DATETIME column. This will take less space and you can use MySQL's (weird and quirky but better than nothing) date functions.
Consider using UNSIGNED BIGINT for all your ids, especially the events. 2 billion seems like a lot, but it sucks when you run out. I've had it happen.
Don't bother with limited length VARCHARs, just use TEXT. It all takes up about the same amount of disk space. Your data schema should not be enforcing business rules.
I want to design a traffic exchange script that counts incoming traffic and tries to return a n:m (1in:2out for example) ratio of traffic. In the database, I want to have the sites info (SITE), then track traffic by site and ip (DAILY-HITS), then I want to have the trade counted per hour or day - not sure yet (SITE-TOTAL-HITS). I would love any suggestions I can get for designing a well designed database for handling traffic trades.
Right now I'm worried about tracking the incoming hits, later worry about returning. So basically my real question is, how can I design a database that can be efficiently used for returning the perfect amount of traffic for say the last 24 hours. The problem I'm having is, when it comes to programming, I want to have the best designed database for getting information on the last 24 hours and making sure I stay within the n:m ration. Heres what I've designed so far for the database:
SITE (just basic info):
id,
url,
title,
description.
DAILY-HITS:
id,
site_id,
ip,
date (include time - will be broken down per hour),
amount (count how many hits from this ip for this hour).
SITE-TOTAL-HITS (probably be updated every hour via script - useful later for counting last 24 hours):
id,
site_id,
year,
month,
day,
hour.
Any tips, suggestions or point me in the right direction would be greatly appreciated. Thanks in advance.
Here is my take on it for what it's worth:
Site:
Same as what you have
Traffic:
id,
site_id,
ip,
request_DateTimeStamp <- this is a date and time for the url request
no count here, just logging here is why:
assume you do have a count column
- url is requested
- lock up a record in the database with the same date and hour and ip
- Found, update the account
- Not Found, Create a new record and set the count to 1
this is a long process for a table that will presumably be updated a lot, within an hour span multiple request from the same ip will try to update the same record and they will have to wait on each other.
take out that count column and your process is simply to log the incoming traffic by always creating new records.
as far as data analysis is concerned, you can do it in couple of ways:
you can try building cubes: http://datacharmer.blogspot.com/2010/01/multi-dimensional-cubes-in-mysql.html
or you could create information aggregation tables like site_total_hits and just update them using nightly jobs or is often as you wanna run them depending on how accurate they have to be.
these are my 2 cents :D
You can use HitLeap to do that.
What is HitLeap? HitLeap is a Traffic Exchange, also known as an autohits service We help you increase your website hits, rankings (alexa, google) and more. Our affiliate program gives cash and traffic commissions of up to 50%. How does it work? After signing up, you will submit all the websites you want to send traffic to. Then you will earn free traffic by viewing other people's websites. Alternatively, you could buy a traffic package from us.
Go tho this link to sign up
I'm developing an application that
stores an e-mail address (to a user) in a table.
stores the number of days the user would like to stay in the table.
takes the user off the table when the number of days is up.
I don't really know how to approach this, so here are my questions:
Each second, do I have the application check through every table entry for the time that's currently stored in, let's say, the time_left column?
Wouldn't (1) be inefficient if I'm expecting a significant number (10,000+) users?
If not (2), what's the best algorithm to implement for such a task?
What's the name of what I'm trying to do here? I'd like to do some more research on it before and while I'm writing the script, so I need a good search query to start with.
I plan on writing this script in Perl, although I'm open to suggestions with regards to language choice, frameworks, etc... I'm actually new to web development (both on the back-end and front-end), so I'd appreciate it if you could advise me precisely.
Thank you!
*after posting, Topener asked a valid question:
Why would you store users if they won't get requested?
Assume the user is just sitting in the database.
Let's say I'm using the user's e-mail address every 5 minutes from the time the user was added to the database (so if the user's entry was born at 2:00PM-October 18, the user would be accessed at 2:05, 2:10, etc...).
If the user decides that they want out of the database in 10 days, that means their entry is being accessed normally (every 5 minutes from 2:00PM-October 18) until 2:00PM-October 28.
So to clarify, based on this situation:
The system would have to constantly compare the current time with the user's expiration date, wouldn't it?
you should not store the time_left variable, bt you should store vaildTo. This way, whenever the user is requested from the database, you can check if it is valid.
If not, then do whatever you want with it.
This approach wont let you make any cronjobs, or will cost you extramload.
Hey Mr_spock I like the above answer from Topener. Instead of storing a number of days the user would like to be valid, store the day the user would like to be be removed.
Adding a field like validToDate, which would be a DATETIME field type, you can do a query like
delete from tablename where validToDate <= NOW()
where
the italicized text is a SQL query
tablename is the name of the table in question
NOW() is a valid sql function that returns the current DATETIME
validToDate is a field of type DATETIME
This has what ever efficiency SQL server promises, I think it is fairly good.
You could write a separate program/script which makes the delete query on a set interval. If you are on a Linux machine you can create a cron job to do it. Doing it every second may become very resource intensive for slower machines and larger tables, but I don't believe that will become an issue for a simple delete query.
I have a case that what will happen when at one end Admin is editing the Details of user "A" in a table "users" and at the same time user "A" itself edits its details in table users. Whose effect will reflected.. And what can be done to make it specific to some one or to give the priority?
Thanks and Regards...
As Michael J.V. says, the last one wins - unless you have a locking mechanism, or build application logic to deal with this case.
Locking mechanisms tend to dramatically reduce the performance of your database.
http://dev.mysql.com/doc/refman/5.5/en/internal-locking.html gives an overview of the options in MySQL. However, the scenario you describe - Admin accesses record, has a lock on that record until they modify the record - will cause all kinds of performance issues.
The alternative is to check for a "dirty" record prior to writing the record back. Pseudocode:
User finds record
Application stores (hash of) record in memory
User modifies copy of record
User instructs application to write record to database
Application retrieves current database state, compares to original
If identical
write change to database
If not identical
notify user
In this model, the admin's change would trigger the "notify user" flow; your application may decide to stop the write, or force the user to refresh the record from the database prior to modifying it and trying again.
More code, but far less likely to cause performance/scalability issues.
We have developed an online quiz where users can register a team to take part in the quiz.
There is a check in the asp to see if that teamname has already been submitted, and if it has, an error is generated.
We have noticed a problem if 2 teams are registered at exactly the same time with the same name, that both teams are registered. Although this is highly unlikely, we wondered what approach should be used to overcome this.
We are using mySql as the database if that makes any difference.
Thanks for any guidance.
Don't worry this never happens.
Databases are smart enough and handle concurrency isuuses.
If you run a query on database for registering a team and another team register at the same time, at database level the first query (when it's send to database) succeed and the second fails with an error which you should take care of. If registeration needs actions more than a simple insert on a table then you should use transaction objects at your queries/store-procedures.
You can set the name column to be unique, and the database will throw an error on the second insert. If you want to do it in code, it will be more complicated.
Not sure how two teams can register at exactly the same time - even if the requests are submitted simultaneously (down to the nanosecond), your transaction semantics should still guarantee that one of them is "first" from the database point of view.