New Desktop Database
-
I'd use LebreBase over Microsoft Access. . .
-
@BRRABill said:
For simple DBs why not just leave it in Access?
Let's reverse that.... why would you ever not take the tiny effort to not do something good? Why set yourself up for problems when you can avoid them? Why would you choose the bad option when good options are freely available?
Access is...
- Not a serious database by any measure and not meant to be used for anything beyond learning and demos.
- Not taken seriously by IT pros and there is essentially no one knowledgeable or willing to be knowledgeable on it.
- Not an RDBMS and therefore not designed around multi-user access.
- Not free, which anything in this range should be. Enterprise options are free, why would you opt for less?
- Tied to not being free, updates are not free. You pay today, you pay forever.
- Not portable. Access only runs on Windows, highly impractical for a database of all things.
- Not scalable. If you need to go big, you can't.
- Not fast. If you want speed, you don't get it.
- Highly subject to corruption. That's not a problem that a database should have.
- Not web based from the application side, this should rule it out right there.
- Not designed to run from a server, this again should just rule it out as a non-starter.
- Not designed to be backed up reliably. This should rule it out, right there.
-
@BRRABill said:
But moving forward I will need to relearn whatever program I am using, whether it be Access on a SQL product.
This is a key here. You are already taking the time to relearn something. Relearn something useful. Don't invest in useless technical debt.
-
@BRRABill said:
I am used to a simple desktop GUI database.
Great time to move away from that. The idea of a "Fat Database GUI" running on a desktop is long, long over. It was needed in the 1990s but is an idea long since past its expiration date. All of these kinds of applications (they are apps, not databases) are just remnants of another era and exist only for people who have invested in their technical debt and are trapped. You should never be implementing them new or choosing them out of "desire." They have their place as lot of companies have huge investments in Access, Filemaker, etc. that might have even made sense when they started but now cost them horribly. Don't voluntarily put yourself in that position.
This is your chance to fix the kinds of things that we have talked about in other threads - things like:
- Never store critical data on your desktop.
- Never make your desktop have to be restored quickly.
- Don't treat your desktop as a server.
- Question any practice that even makes you want to back up your desktop at all.
If something is so simple that you can make it in Filemaker, Access, Paradox, etc. then it should be pretty simply to make in PHP, RoR or similar. Once you are making the effort to invest in something, invest in the future, in things that will add the most value.
-
If you are doing something "super simple", I would almost certainly go for PHP + MariaDB. Both are very simple and have nearly unlimited tools for working with them. Fire up a CentOS 7 or openSuse Leap 42.1 VM and go to town.
-
The only question would be the amount of time it would take him to learn to use PHP+MariaDB and get them to do what he wants. This is fine if he A) Has the desire to learn, and B) Has the time to actually learn to code it.
Whereas moving from Access to something like LibreOffice Base would still have a learning curve, I'd be surprised if he could learn and develop a PHP Database App and implement a reporting engine for it in less time than he could learn to use Base.
Now if he could find a PHP App that already does what he wants it to do... That'd be a different story.
As a good compromise, he can use LibreOffice Base (or Access) and Link to the tables in MariaDB. That way all his data is stored on a server, and he can still have an easy way to write reports, etc.
-
Yeah I really don't do any sort of complicated stuff.
This is stuff the wizards would probably be able to handle.
I definitely get your point about learning something better, though.
-
What makes this mailing list so special that it requires a DB in the fir,....
Never mind.. I see a point. If you are using the mailing list to track donors year to year,.. you need a DB for updates to a person. Mailing lists I have done in the past have been simple and were done in Excel...
-
@BRRABill said:
Yeah I really don't do any sort of complicated stuff.
So that rules out desktop database products!
-
@gjacobse said:
Never mind.. I see a point. If you are using the mailing list to track donors year to year,.. you need a DB for updates to a person. Mailing lists I have done in the past have been simple and were done in Excel...
Excel will do that. Excel will front an RDBMS.
-
@dafyre said:
Whereas moving from Access to something like LibreOffice Base would still have a learning curve, I'd be surprised if he could learn and develop a PHP Database App and implement a reporting engine for it in less time than he could learn to use Base.
It's not just time to get up and running but TCO. Over time that Access system will get more and more cumbersome. The PHP approach will remain simple, easy and free. Over time it is the cheaper option.
-
Well, that's another way to move with this.
The main things I use Paradox for and not Excel are:
- nth selection of sample
- multiple simultaneous comparisons of data (if I have to match multiple fields in the same database, say first name, last name, city, and two other codes)
That's about it.
-
These are like 1 time things, maybe a few times over a few weeks, then I never go back to the DB.
-
@BRRABill said:
Well, that's another way to move with this.
The main things I use Paradox for and not Excel are:
- nth selection of sample
- multiple simultaneous comparisons of data (if I have to match multiple fields in the same database, say first name, last name, city, and two other codes)
That's about it.
I hate saying this but.... it almost sounds like you could do this more easily in straight SQL and not have any front end at all.
-
@scottalanmiller said:
It's not just time to get up and running but TCO. Over time that Access system will get more and more cumbersome. The PHP approach will remain simple, easy and free. Over time it is the cheaper option.
How does using Access get more cumbersome? Because of version upgrades, etc?
You run into that with PHP as well (arguably at nowhere near the scale that you could see in Access).
-
Are you able to provide a sample? What what example does the data look like (three lines is fine) and what does a query look like?
-
@dafyre said:
How does using Access get more cumbersome? Because of version upgrades, etc?
Version upgrades, paying for version upgrades, being locked into an enterprise-only product family, being locked into a product that appears to be well along the phase-out path, having to be on Windows, compatibility, etc.
-
@dafyre said:
You run into that with PHP as well (arguably at nowhere near the scale that you could see in Access).
No he should not. Deploy on Linux, system is self maintaining for a project of this nature. Everything updates itself. Nothing to worry about.
-
@scottalanmiller said:
No he should not. Deploy on Linux, system is self maintaining for a project of this nature. Everything updates itself. Nothing to worry about.
And then when PHP upgrades to a version that is not compatible with his PHP application?
I get your point though.
What about using something like Base? You get the benefits of Access (easy to use, lower learning curve if you are coming from Access), but you also get cross-platform compatibility, no paying for version upgrades, or being locked into Windows.
-
@dafyre said:
And then when PHP upgrades to a version that is not compatible with his PHP application?
Doesn't really happen. I assumed that that was your concern in the previous thread. If you wrote normal PHP going back 15 years, it still runs today. No changes.
