Of course, in order to save and update each of these, the Rails
application requires the DB communication every time; namely, the number
of columns.
And for another case, I have a long but SINGLE text column like,
st1, st2, st3... :text
Editing it is to be achieved at local computers with JavaScript. For
this, in order to save and update, the application needs the DB
communication only once.
Both of them have the same amount of data in terms of characters.
My question is:
Which of these types of DB structure would you suggest in order to
minimize DB transactions? (or in order to avoid possible errors...)
Of course, in order to save and update each of these, the Rails
application requires the DB communication every time; namely, the number
of columns.
Wrong, it will read the whole record in one go.
And for another case, I have a long but SINGLE text column like,
st1, st2, st3... :text
Editing it is to be achieved at local computers with JavaScript. For
this, in order to save and update, the application needs the DB
communication only once.
Both of them have the same amount of data in terms of characters.
My question is:
Which of these types of DB structure would you suggest in order to
minimize DB transactions? (or in order to avoid possible errors...)
Don't worry about efficiency at this point, design the app and
database in what seems to be the most logical and simple manner. Then
you will get something going quickly and with the simplest code (so
with less bugs).
It is most unlikely that any bottleneck in your app will end up being
where you think it is at this stage of development, it will be
somewhere that you least expect it. Once you have it all up and
running then you will know whether you actually have any performance
issues (which is unlikely in fact) and can then re-factor if
necessary.
In terms of the database design, however, if your model has an
indeterminate number of strings, you should consider the removing the
strings from the table and using a separate string table with a single
string in each record. Than your first model has_many strings