gaborous

@Kickstart I hardly see how one would ever want to search through the saved game states... The sole usage is to reload a previous game, it's purely functional. And anyway even if that was the case, how would you do that in a relational schema if you have to manage different games? You'd need to have a static schema to design a relational one, which is clearly not the case here. Or you would have to create a static schema that is the combination of all parameters of all games states, which would just explode your database in addition of having lots and lots of null columns except for one game..

@Kickstart I specified "data that is not meant to be searchable", thus not meant per se (depending on the data itself), not due to planned usage. See the excellent example of saved data games by fdreger below: this is the kind of data that is never meant to be searchable, and I can't imagine one case that it would be needed. Also, designing for every usage possible can lead to feature creeping, and usually leads to a design more difficult to change.

@Kickstart agree but if the data you store in a blob is not meant to be searchable anyway, there's no harm possible.

@T.J.Crowder If I read correctly, OP didn't say that his professor claimed this way is better, rather that this is a possible design that can make perfect sense for some applications, which I can agree with.

Also I would add that it was a bad idea in the first place for a couple to work at the same workplace. It blurries private and professional life, and it makes this kind of event (splitting up, cheating, etc.) very difficult to handle. So the situation is unfortunate, but J & J chose to take the risk, and now it's up to them to manage the (private) problem.

Depends on your definition of a fact: whether it is a truth bearer in itself or if it is an expression of an aspect of the world, in which case it may be false: plato.stanford.edu/entries/facts/#FacFacFac

I'll check out here once in a while, but if I forget don't hesitate to ping me by commenting on SO!

Ok no problem :)

Ok for the edited version's length, it's perfect :) Thank you for your efforts!

But thank's about the link, I will keep it in my list of refs :)

"Why do HDDs die so often?[...]": the demagnetization I talk about is because of current fading away with time. So yes indeed the bits cannot be demagnetized by placing a magnet close to the HDD because the casing is made to isolate the hdd's magnetic disk, but it cannot prevent the current from flowing away with time. I have found a few papers quantifying the time demagnetization, but I can't put a direct ref because of length constraints :/

About file fixity, yes this is actually the most precise term we can coin for what asked the OP: making sure the files don't change with time (ie, they remain "fixed"). I wanted to make a link to wikipedia's definition, but SO's length constraints also applies to links unluckily :(

Some sentences phrasing may not be the most syntaxically or semantically correct but I had to cut down on the words because of the post length limit :/ So if you suggest other sentences, please make sure they are of the same length at most

I'm not sure if preservation is more accurate than archival. Both are commonly used by specialists so I would say they are equivalent for this purpose.

Thank you for your feedback, I will fix the post with your inputs

(or if someone knows a good mailing list or forum where I could ask)

Hi there, is there someone experienced with Reed-Solomon and more particularly erasures-and-errors Berlekamp-Massey decoder?