the suggestions above all leverage a Linux based extension to the board so the Arduino (ATMEGA328/2560 etc) is not managing the DB, it is simply sending commands to the Linux based system to do it remotely
remotely being maybe an inch away to over the internet
What you can do is have the data saved to a file on the SD card and have a PC/PI poll the Arduino for the data on a scheduled basis and load it into a database or even have the Arduino send it via wireless / ethernet / serial out to a listening device (Web server, PC, PI, Other) where it can be processed.
at the end of the day, ask yourself, is the database actually necessary, what is your final output for a user, what are you trying to do with he data ?
You simply have a separation between data collection and subsequent processing / viewing
As Peter points out people are not trying to jam full database functionality into arduino uno platforms because most applications can find better ways to meet their data needs.
However, it is likely possible to implement a limited scale database on an arduino uno, as this CPU is more powerful than the original IBM PC, but you would might need to program your own database from scratch.
There are many arduino examples of data collection to SD card with proper library support and even direct feed of data to external databases. If you need suggestions on how to solve or optimize your data requirements, you just need to specify what those requirements are - like how much data, what data rates, what processing is done on the data, how does the data need to be displayed, etc.
As Peter points out people are not trying to jam full database functionality into arduino uno platforms because most applications can find better ways to meet their data needs.
However, it is likely possible to implement a limited scale database on an arduino uno, as this CPU is more powerful than the original IBM PC, but you would might need to program your own database from scratch.
There are many arduino examples of data collection to SD card with proper library support and even direct feed of data to external databases. If you need suggestions on how to solve or optimize your data requirements, you just need to specify what those requirements are - like how much data, what data rates, what processing is done on the data, how does the data need to be displayed, etc.
Possible yes but not really viable as with such limited RAM even with a 2560, you would rapidly run out of space for real work. Collecting the data and even persisting it on an SD card for later processing is probably the best way to go as it minimizes the overhead on the sensor node and really it does not need to pretend to be a database.
By the time you get enough RAM or storage to justify a DB then your probably already exceeding the price of a PI/RIOT/Other linux based system that could off load this for you and have room to be a master controller as well.
I would definitely advise taking the distributed approach. IO/Sensing logging etc on a small cheap controller, then upload to a more capable board / PC for processing and display
