Jump to content
Sign in to follow this  
MvGulik

Saving/storing lots of objects.

Recommended Posts

MvGulik

Suppose I have a lot of Objects or Elements with properties. (not necessary AutoItObjects, but I will probably use them in the app internally.)

How or what would be a good way of storing that kind of data.

I figure using a database would probably be best. (SQLite in this case. And active used database, so not just saving and loading at App start and shutdown.)

But considering the amount of objects and the additional possible relations between different objects/element ... I image it becoming a spaghetti-fied mesh real fast unless I find a good way of organizing the data in the database.

I know its not much to go by. (A full user adjustable object manager would probably be a more appropriate description. :blink: )

Any tips or links that might help me find the prober point of view for this?

Edited by MvGulik

"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites
LurchMan

Some sort of SQL DB would be the best solution for something like this. If you plan on using SQLite then the help file that comes with AutoIt for SQLite will help you with getting it built and configured the way you want it.


Dating a girl is just like writing software. Everything's going to work just fine in the testing lab (dating), but as soon as you have contract with a customer (marriage), then your program (life) is going to be facing new situations you never expected. You'll be forced to patch the code (admit you're wrong) and then the code (wife) will just end up all bloated and unmaintainable in the end.

Share this post


Link to post
Share on other sites
PsaltyDS

I haven't tried it, but doubt you can save an AutoIt Object variant that way, and still use it when retrieved.

I have done this by saving Objects in AutoIt arrays, or even a Scripting.Dictionary.

Since object references are only valid at run-time there is probably no point in trying to save them to a file of any kind.

:blink:


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
MvGulik

Some sort of SQL DB would be the best solution for something like this. If you plan on using SQLite then the help file that comes with AutoIt for SQLite will help you with getting it built and configured the way you want it.

I know. I'm just not a that stage yet.

PS: There is no such thing as a "SQL DB". But I get your point.

---

I haven't tried it, but doubt you can save an AutoIt Object variant that way, and still use it when retrieved.

I have done this by saving Objects in AutoIt arrays, or even a Scripting.Dictionary.

Since object references are only valid at run-time there is probably no point in trying to save them to a file of any kind.

:blink:

Mmm. I did not spend any serious thinking on that problem part yet, but I see your point.

Although saving and reloading of true Objects ref's is not really something thats needed I think. A dedicated Object manager should take care of the creation, linking, unlinking and storing of a general Objects ref's for the data-objects. (I know, It sounds easier that it is.)

---

One thing that crossed my mind was that if I do have a good DB storage(actively used) for the data and data structures(element relations) in question. The need/usefulness for using Object variants will drop to temp data container only (element properties), but without the need to contain any direct object ref's to/for other Element-Objects. These element relations would come, or link, from/to the DB. (probably cached in some List or other special Object)

If I use a static storage method. One that is only used to do a full read and write of all the data in question. At application startup and shutdown for example. This would be a lesser problem.

Things that are on my mind in relation to data storage:

- Static disk-storage: All data is transfered between app an disk in one go. Pro) General App speed, Con) App memory use.

- Static disk-storage: Need some way to maintain Element(objects) relations (Objects ref's). Object ref's administration will be done with a dedicated Object manager.

- Static disk-storage: Using a database for data storage is not really needed or mandatory in this case.

- Active disk storage: On demand Data read and write. Pro) App memory use, Con) General App speed. (although the app is not speed sensitive, so the real issue/choice is what would be easier to maintain from a data and coding point of view. Without using a obseen amount of memory.)

- Active disk storage: If Element relations are easily readable from the DB. There is no need to do a full second object ref administration. (only a currently loaded Elements(active objects) list maybe.)

---

... I'm not going to get anywhere by only thinking about it ... Will see if I can rack-up some test case/code to experiment with.


"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites
jchd

Your thought are currently too vague to be a ground for any decision, IMHO.

What in generic SQL keeps you from storing / querying object-like data? You can do it all with regular tables, joins and foreign keys.

If you encapsulate all operations on your "objects" --whatever they actually are-- you can even obtain object persistance. How that is done is an implementation detail.

If you insist on applicative code compactness with good OODBMS support, then it's obvious that AutoIt isn't the right choice for a significant application. C# and .NET have some support AFAIK (DLINQ).

Now about efficiency, what are your requirements? How many objects would you be wanting to process per second? How many concurrent users are planned? How large would the whole thing be, roughly? How much memory can you afford to DB cache?

Can you come up with a simple everyday's euphemism to expose the practical issues you need to address?


This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.