Best way to store data

  • Thread starter Thread starter Crirus
  • Start date Start date
Well, what I want to search is some data from certain fields like in a
database.
One use is that to prevent multiple records with the same email address to
be added...as an exemple
 
Crirus said:
I have about 1000 records of users to store.. I dont like the ideea of a
database server...
Click to expand...

Hi again,

You received some interesting answers and I think we can see why you
wouldn't want to setup and maintain SQLServer for 1000 records but I'd like
to suggest that you explain the "purpose" it makes such difference in the
responses you will get.

I see later on you wrote "firstname, lastname, age... username, password"
and such. So it sounds like a database for keeping track of users. Is this
sitting on a server (for use by the server) or is the client software going
to perform the verification?

If it's on the server loading all the names in the file is no big deal, it's
a bit more of a deal if you have to stream them all to every client in order
to check whether that client typed in the correct password.

How "can" I isn't too hard to figure out... how "should" I is a bit harder.
BTW... you shouldn't store anybody's "age" it changes every year and you
won't know when.

Tom
 
How "can" I isn't too hard to figure out... how "should" I is a bit harder.
BTW... you shouldn't store anybody's "age" it changes every year and you
won't know when.
Click to expand...
ROFL
 
Crirus
It is for server side pourpose
Click to expand...

Than I don't see any benefit for a XML file.

A XML file is primary ment to transport data, not in first place to hold it.
(Although you can do that)

Cor
 
Hi Cor,

|| Than I don't see any benefit for a XML file.

Simplicity for one. What's simpler than a text file sitting on
a hard drive? Loading and saving it is almost a one-liner.

|| A XML file is primary ment to transport data, not
|| in first place to hold it. (Although you can do that)

Surely not!?? SOAP is for transport. Xml just happens to be
what SOAP contains. There's a whole language (XSLT) devoted
to manipulating Xml data. And there's the Xml DOM. What are
these both for, if not because Xml is all about data?

I'd say that Xml's primary purpose is to hold data. And that it's
also handy for transporting it! ;-))

Regards,
Fergus
 
Ok Fergus,

I take this
Simplicity for one. What's simpler than a text file sitting on
a hard drive? Loading and saving it is almost a one-liner.
Click to expand...

Of course you can use XML to store data, but not when it is subject of
frequently changes and certainly not when more than one process in a time
has to do updates on it.

By instance when you have to change somebody's age or whatever, you have to
disconnect your process a while, just because you have to delete it and save
it again, you cannot do partential updates on a XML file, reading and
writing is a streaming process.

Cor
 
Hi Cor,

|| Of course you can use XML to store data, but not when it is
|| subject of frequently changes and certainly not when more
|| than one process in a time has to do updates on it.
||
|| By instance when you have to change somebody's age or
|| whatever, you have to disconnect your process a while, just
|| because you have to delete it and save it again, you cannot
|| do partential updates on a XML file, reading and writing is
|| a streaming process.

And I take this ;-)

Yes there's management involved. It's still a viable solution with
low-volumes - size of database and number of accesses.

In Crirus's case, for instance, he's only got c1000 users and the
record size is small so we're not talking seconds per update - more
like number of updates per second, I'd guess. And as it's unlikely
that they will all be on at once, let alone accessing their info, the clash
between simultaneous readers and writers is going to be pretty rare.

I wouldn't say this if the actual game-play data were stored in this
table though.

I reckon that eventually there will be enough users, and the record
size will expand as more fields are added, such that another solution is
required. But for now, I would say that Xml is a simple solution that
could help reach the production deadline.

Regards,
Fergus
 
Hi Fergus,

Problem for me is, that I tried it once in that way.

I think MSDE or MS Access will be better in this case.

But when he does not want either one of those, than XML is one of the best
from the worst.

But when Crirus wants to do it, he sure has to make it in this way.

ds.xmlread(xmlfile)
rename xmlfile
do some stuff
ds.xmlwrite(xmlfile)
delete renamed xmlfile

I have some expirience with it :-)))

(Did you see that genealogic website of my, it is all build on this
solution).

Cor
 
Well, I dont think I will modify the xml too often, only few times a day, as
some new player create an account...more, I will search in it for pass
validationg and stuffs
 
Crirus said:
Well, I dont think I will modify the xml too often, only few times a day, as
some new player create an account...more, I will search in it for pass
validationg and stuffs
Click to expand...

You really (probably) don't want to use XML. It doesn't matter if you only
update a couple of times a day. If you want simple and effective then
choose the solution that has been used for decades.

Random-access fixed-length text files were designed for simple data access.
You can read/write to/from any record, you can search, you can append...
deleting is handled by adding a delete field. If you want to skip the
appending part you can simply define a block of 2000 records and if your
guess of 1000 is correct you won't overrun it.

I'll guess that today's computers can handle it since I used it effectively
on 1MHz CPUs 15 years ago. And dBASE files are exactly this format BTW with
one special header record added at the beginning.

Tom
 
Hi Tom,

This hits me.
You really (probably) don't want to use XML. It doesn't matter if you only
update a couple of times a day. If you want simple and effective then
choose the solution that has been used for decades.
Click to expand...
We agree but. XML has an advantage that is not in the database solutions
that are used for decades (not for the problem from Crirus, because that is
to simple).. XML has Complex datatypes.

If you don't know it, that means that you can name something "House" and
than divide that in elements like "kitchen", "mainroom", etc. That you can
divide again very deep. But all are always related to the parent root.

As far as I know is that in the todays databases impossible. You have to
create all seperate tables for it, with in a way complex relations using
keys.

I think the XML structure is better than the current generation databases
but I think it will be a big road to go before the databases have that
advantage also.

Just a thought of me which I have for a long time.

Cor
 
Cor said:
Hi Tom,
This hits me.
Click to expand...

It was unintentional I assure you :-)
If you don't know it, that means that you can name something "House" and
than divide that in elements like "kitchen", "mainroom", etc. That you can
divide again very deep. But all are always related to the parent root.
Click to expand...

Sure... it does a fine job of representing data.
As far as I know is that in the todays databases impossible. You have to
create all seperate tables for it, with in a way complex relations using
keys.
Click to expand...

There are object-oriented database servers. But the reason that relational
databases work like they do (and not like XML) is that they are relational
databases and not XML :-)
I think the XML structure is better than the current generation databases
but I think it will be a big road to go before the databases have that
advantage also.
Click to expand...

The concepts have been around for a very long time. It has now been defined
using SGML syntax and has gained acceptance but it is doubtful that any kind
of XML formatting will "replace" relational databases. It wouldn't be
unlike suggesting that a CPU should operate on a base 10 numbering system
because humans find it easier. As long as the output can be formatted as
XML it doesn't much matter what is happening inside the box.

In any case the task that Crirus has outlined doesn't warrant it. It is a
simple case solved by a random-access file. He can use XML but it should
operate faster, be easier, cost less or have some other benefit to warrant
the effort. He can even change his mind once he has it operating...

Tom
 
Well, I started with the XML ideea...mainly because I make my money from
creating XML documents on the firm I work for... This is a home project,
with firm backup if is succesfull :D

And I could edit that xml's by hand any time I like, so it's more flexible.

Meantime, I have some questions related to DataSet....

How can I filter records on a table...I tryed MyTable.Select("FirstName=a")
but seems that doesnt kors, it say there is no column named "a"

Should I use 'a'?

Is there a compliance with WHERE clause of an sql query in this?
 
Crirus said:
Well, I started with the XML ideea...mainly because I make my money from
creating XML documents on the firm I work for... This is a home project,
with firm backup if is succesfull :D
Click to expand...

Using what you are familiar with is always a good idea.
And I could edit that xml's by hand any time I like, so it's more
Click to expand...
flexible.
Just so you know you can edit a random access file by hand also but again
whatever works for you is the best choice..
Is there a compliance with WHERE clause of an sql query in this?
Click to expand...
I don't know but I assume there is.
 
Back
Top