如何在物理RData中直接使用data.frame？

Question

Do I have to

1) load a data.frame from the physical RData to the memory,

2) make changes,

3) save it back to the physical RData,

4) remove it from the memory to avoid conflicts?

Is there anyway I can skip the load/save steps and make permanent changes to the physical RData directly? Is there a way to work with data.frame like the way working with a SQLite/MySQL database? Or should I just use SQLite/MySQL (instead of data.frame) as the data storage?

More thoughts: I think the major difference is that to work with SQLite/MySQL you establish a connection to the database, but to work with data.frame from RData you make a copy in the memory. The later approach can create conflicts in complex programs. To avoid potential conflicts you have to save the data.frame and immediately remove it from the memory every time you change it.

Thanks!

Answer 1

Instead of using load you may want to consider using attach . This can attach the saved data object to the search path without loading all the objects in it into the global environment. The data frame would then be available to use.

If you want to change the data frame then you would need to copy it to the global environment (will happen automatically for most editing) and then you would need to save it again (there would not be a simple way to save it into a .Rdata file that contains other objects).

When you are done you can use detach (but if you have made a copy in the global environment then you will still need to delete that copy).

If you don't like typing the load / save commands (or attach / detach ) each time then you could write your own function that goes through all the steps for you (and if the copy is only in the environment of the function then you don't need to worry about deleting it).

You may also want to consider different ways of storing your data. The typical .Rdata file works well for an all or nothing approach. The saveRDS and readRDS functions will save and read a single object (and do not force you to use the same name when reading it back in). The interfacing with a database approach is probably the best if you are making frequent changes to tables and want them stored outside of R.