Saving/storing lots of objects.

[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. )

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

Edited July 9, 2010 by MvGulik

[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.

[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.

[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.

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.

[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?