flat assembler
Message board for the users of flat assembler.

Index > Heap > flat file database versus sql server

Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 8870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
while,everybody deal with database whether they realize or not,, and since not everybody deal with "corrupted" database,

I assumed corrupted text file is more easier to repaair than corrupted database server.... does it somehow mean,,i should use flat file database? Maybe not so efficient, but at least save the headache if it corrupted????
Post 30 Nov 2010, 21:06
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The use of the databases is mainly because the information in the database is structured and classified and the access to the data is maintained in standard way. Also, the database engine automatically attends for data integrity, so data corruption is very unlikely to appear (what is not the case for plain text or binary data files).
The reverse of the medal is the extra resources you need in order to use any database engine - I mean memory and speed. Most of the database engines are multi-megabyte monsters, that needs all the resources of your computer and wants more. Wink
Actually in this very moment, the only (more or less) usable database engine for assembly written programs is SQLite. It is far from ideal, but at least is acceptable...
Post 30 Nov 2010, 22:21
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
Quote:

data corruption is very unlikely to appear

but such thing still happened in mysql or mssql (maybe during backup or restore or etc cases)...

and the chances to have "somebody" able to repair the database is "lower" than those flat file or text file database...

sqlite works,,,

but am more "considerate" if let say they somehow corrupted.... how am i gonna "repair", "restore" or etc in an easy way??

....?
Post 01 Dec 2010, 15:30
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
versionning and transactional database with ECC
Post 01 Dec 2010, 15:51
View user's profile Send private message Visit poster's website Reply with quote
ass0



Joined: 31 Dec 2008
Posts: 521
Location: ( . Y . )
ass0
sleepsleep wrote:

but am more "considerate" if let say they somehow corrupted.... how am i gonna "repair", "restore" or etc in an easy way??

....?


ez way == backups

_________________
Image
Nombre: Aquiles Castro.
Location2: about:robots
Post 01 Dec 2010, 16:26
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
IMHO, the wide use of human readable data files recently is simply because the low quality of the software and the wide use of HLL with good string processing libraries. Smile
Using ASCII files to keep data is an unnecessary waste of processor time, memory and resources.
Maybe acceptable for HLL programmers, but an assembly programmer should not tolerate such things. Smile
Post 02 Dec 2010, 07:05
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
sleepsleep wrote:
JohnFound wrote:
data corruption is very unlikely to appear
but such thing still happened in mysql or mssql (maybe during backup or restore or etc cases)...
If you get database corruption on one of the proper databases (mssql, postgres, db2, oracle, and probably even mysql and sqlite), something Very Bad(TM) has happened, and you can be pretty sure that a flat file wouldn't have been in a better state.

The above mentioned databases follows the principles of ACID - the Atomicity and Durability are pretty nice aspects. Your server crashes in the middle of a transaction? Fine, reboot it and replay the log file, and you're back in shape. Doesn't help against crashing harddrives, that's what you have backups for.

JohnFound wrote:
Using ASCII files to keep data is an unnecessary waste of processor time, memory and resources.
Maybe acceptable for HLL programmers, but an assembly programmer should not tolerate such things. Smile
You don't do much systems integration, eh? Wink

Tongue-in-cheek aside, I (mostly) agree with you. For larger amounts of data, I prefer fast binary storage formats; the perverse overuse of XML bugs me. It's one of the reasons that OpenOffice is so ungodly slow - the OOXML MS Office versions are better, but partially because they hide some of the overhead by running saves in the background.

I most definitely prefer formats to be open, though, and for interchange text-based formats can make your life a helluvalot easier.

_________________
Image - carpe noctem
Post 02 Dec 2010, 08:25
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
Quote:

but an assembly programmer should not tolerate such things

hahak Smile

yeah, i agree, backup is damn important.... but my concern is more to, if let say, something very bad (TM) happened,... the chances of getting back the records.... if let say, sql server, it could probably means i need to spend whole lot more time to understand how the sql server stores things.... perhaps i need to beg a database guru.

if let say text file, perhaps, it could be more general and perhaps, somebody with not so "deep db skill" could help me to solve it or i solve it on my own.

regarding replay the log file, isn't it saved in text file? hmmm,, did they save log file in database too nowdays???
Post 02 Dec 2010, 15:40
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The replay log has never been a text file - I can see how the word "log" can be confusing if you're not familiar with DBMS Smile. It's a binary format, and a lot of care is taken to ensure things are written in the correct order, also with respect to filesystem caching etc.

Again: if a machine crashes hard enough that a database (using a proper DBMS) is corrupted, you're unlikely to have had more success with a flat format.
Post 02 Dec 2010, 16:39
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.