vector vs hashtable

[Leo Max]

this is very tiring...
i have an online site where records are strings and the server has images too. think of a profile. you have a reocrd for the user where the fields are name age number and the image corresponding to a user. i wrote the code to download the data where there's an rms for the images and another for the strings.
my first attempt was to use 2 vectors. vector1 has objects where each corresponds to a user's profile (strings) and vector2 has the image. but then i thought, 2 vectors .. maybe i should just store them in one vector. better right? so i went ahead and did it. first the string objects then the images. so vector1 has 4 objects (strings) followed by 4 images. but now i have a problem. what happens when i download new records? according to my ONE VECTOR, it'll be old string objects old images new strings objects new images. that makes no sense. so i thought ok everytime i download stuff, i create a new vector, save new string objects then move the old string objects from the old vector to the new one. same goes for the old and new images. then i empty the old vector and set its size to 0. so, old vector is empty. new vector has new string objects, old string objects, new images, old images. but thts not good. imagine having 100 string objects and 100 images. you're going to move these to a new vector on a mobile with limited capabilities? NO! you can tell me no, just use a forloop to move the images down x times so that you can insert the new images and strings in between. thts still bad for performance. probably!
so then i thought ok hashtables! that should be better. mayb hashtables improve performance over vectors. the key is the string object and the value is the image. now i have a new problem. the sweet thing about a hashtable is that you just need to say GIVE ME THE OBJECT WITH KEY X and it'll load it for you right away. in vectors, you'll have to go through the entire thing until you find what you want. well not the whole thing. depends on where the obj is located. in short, hashtables pawn retrieval wise. but in my case my hashtable might as well be a vector because the key is the string object. which means that when im searching or updating, i'll STILL have to access every key, look in it for the string "19" (if im loking for age for example) and then get the value. do you see my point? even if the key was a string made up of the name age and number each sepereted by a - ("leo-19-0000") thts still no good cuz ills till need to find out if that string contains the age 19.
so i said ok. base on ZERO knowledge i'll just use 5 hashtables. 4 for every string and 1 for the image where the key is the recordID i get when i store the string and image objects in the rms. BUT, 5 hashtables? is that normal? what if i had 10 strings and 1 image???
so i thought ok scrw it. i'll just use the rms when i search. but thts no good either right? performance prbs?
oh and bare in mind, i plan on sorting w/e structure i end up using. and that's a whole topic by itself.
im lost this is no fun -_-

j2me has 2 structures which i can use. vectors and hashtables. each has its ups and downs. i no a little about both. which structure would be best for my app? the functions i perform on my mobile are search, sort, insert, delete, and update.

my life was so much better when i had two vectors but i kept thinking no no there has to be a better way. this cant be good. iv spent a few days doing 2 vectors. then more days trying one vector and hastables. im stuck! any of the 3 methods is fine by me. i just need to choose the RIGHT one to avoid my mobile crashing on me or slowing down.

PLEASE help.


PS. my prb could have been solved with one vector if it let me

[Paul Clapham]

I got lost in all of that, but frankly, if you're working in an environment where storing 10 strings actually creates a performance problem, you have no chance of producing anything useful. You might as well forget it. Target some more practical environment.

[Leo Max]

sorry when i said limited i meant mobiles compared to computers. allow me to explain in less painful details. i spent 30minutes preparing this so i hope it helps

online database has a table of 4 fields: username, name, age, country. the images of every user are stored there as well. the imagename = name of user. so my name is leo therefore my image is leo.jpg

mobile app:
first class is USERS class. in it are 4 declared strings = 4 fields in the database + recordID string

first vector is USERS vector
second vector is IMAGES vector
third vector is NAMES vector

first rms is USERS rms
second rms is IMAGES rms



now for my process:
1- i download the data online. first record is wildheart25c, leo, 19, US
2- i save these 4 strings in a record in USERS rms
3- i create an object of type USERS and save this info in it along with the recordID which i get fromt he previous step
4- i insert this object in USERS vector
5- i insert the name string in the NAMES vector
6- repeat processes 1-5 until all the records have been downloaded
7- i download the images using a for loop. the following steps are what happen inside the for loop
8- save the image in a record in the IMAGES rms
9- insert the image in IMAGES vector
10- repeat until i > NAMES.size();

example just to b sure you're with me so far
online db:
wildheart leo 19 US
maximus tim 19 US

mobile app:
NAMES vector has leo and tim
IMAGES vector has leo.jpg and tim.jpg
USERS vector has obj1 and obj2 where each obj has info about each user and their recordID

Searching:
i access each object in the USERS vector looking for a certain field value like age=19. if i found it in index0 of USERS vector, then i load the image in index0 in the IMAGES vector

Deleting:
access each obj until you find the name you want to delete. when you find it, the obj contains the recordID. use that ID to access the USERS and IMAGES rms and delete that record

Insert:
this means downloading new records. the processes have already been explained

Update:
this means downloading updated records. exiting records with new information. i access each obj until i find the username, change the info in that object, then use the recordID to access the record in the USERS rms to change the info. same goes for the image if there's a new image.

This is what i did and iv tested it on 4 records. no problems. BUT i asked myself if having 2 vectors is a good idea. i have 4 records only. What if i was downloading 100 new records and 20 updated records? would two vectors be a good idea performance and storage wise? and w/e else factor that affects a mobile
So i turned to hashtables. There are two ways to do this using hashtables.
1) 4 fields therefore 4 hashtables. the key is the recordID and the value is each of the 4 strings. So i'll have a hashtable for username, another for name, anther for age and another for country. then a 5th hashtable for the image where the key is the recordID and the value is the image itself.
2) One hashtable. the key is the users object. the value is the image. or the key is one string ("wildheart-leo-19-US") and the value is the image. Either way when searching and updating i'll have to access each obj/string to find what i want. Ths cancels the idea of using a hashtable because im going through every key until i find the one i want which is pretty much the same as going through a vector

Bare in mind that i dont no which sort algo to use. so w/e method you recommend, bare in mind the sort algo that goes with it.


There. I hope this helps. Sorry again.

[Leo Max]

sigh why is there no reply yet? T-T surely it's a lot more clearer now. for any of you. which is it going to be and why? 1 vector or 2 vectors or hashtables (either methods of hashtables)?

[Walter Gabrielsen Iii]

Hashtable is a map, and maps are key to value collections. A map is like a gameshow where you need to pick one of several doors, and, let's say you pick door number 1, so, then, you take the key for door #1 and find the prize you've won.

In your case, instead of searching the Hashtable, you would take the key for, let us say, "username" and discover the value within, such as "wildheart" -- in your case, Hashtable is best used for storing the values of a single user, but not for packing in the values of several users.

Using several users' information it's almost like you need a list of Hashtables (hint, hint...).

Which brings us to Vector, which is a growable list that holds objects (such as, say, a User's Hashtable) in a fixed order, and that lets you call up that object based on its position in the Vector's list --which helps you search, add or delete users if you know the index number that the user is stored in.

In other words:

Hashtable map: [ username | name | age | country | image ]

Vector list:
index item 0. Hashtable leo (which contains the above map with values: wildheart, leo, 19, US, leo.jpg)
index item 1. Hashtable tim
(and so on...)