One user has said to me
Applying incremental db backups is tedious, and a royal pain if you miss a step. I wouldn't bother with the approach on SQL Server or MySQL - that's what transaction logs are for, so you don't need to incorporate it into your data model
So if i have transactions on mysql or sql server i can have a script to backup any data modified after or between date X and Y? I ask because i am currently designing tables so i can do an increment dump instead of a full.
Yes, you could backup the transaction logs rather than incorporate logic into your data model, providing the database supports it. Your previous question said that you were developing on SQLite...
Speaking from a SQL Server background, it can use transaction logs for both restoration and replication of a database. An ideal setup would have three RAID drives setup - a mirror for the OS, RAID 5 (or better) for the data, and RAID 5 (or better) for the transaction logs. The key part is the transaction logs being on their own RAID setup for optimal performance (not competing with read/write for data) and failover (because RAID is not a backup). For more info - see link.
MySQL transaction logs turns up info on the MySQL Binary Log, which also references replication so I figure there's a fair amount of carryover in approach.
On SQL Server: The key factor is the SLA time of recovery. A full a disaster recovery starts from the latest full backup, applies the latest differential backup, the applies all the log backups after the latest differential backup. If you're missing differential backups from your recovery plan, then you must start from the full backup and then apply all log backups.
The differential backup thus reduces the recovery time by eliminating the need to apply all log backups taken between the last full backup and the last differential backup.
If your database is small, differential backups don't add much advantage because the recovery time is small to start with. But on large databases it makes a difference, as the log backups can be quite large and going through days of log adds up to the recovery time. Adding differential backups can cup back the recovery time by few hours.
I'm not sure I follow your argument about designing tables with differential backup in mind, the two subjects are orthogonal.