Best Java data structure to store a 3 column oracle table? 3 column array? or double map?

Question

Hello :)

What is the best data structure to store an oracle table that's about 140 rows by 3 columns. I was thinking about a multi dimensional array.

By best I do not necessarily mean most efficient (but i'd be curious to know your opinions) since the program will run as a job with plenty of time to run but I do have some restrictions:

It is possible for multiple keys to be "null" at first. so the first column might have multiple null values. I also need to be able to access elements from the other columns. Anything better than a linear search to access the data?

So again, something like [][][] would work.. but is there something like a 3 column map where I can access by the key or the second column ? I know maps have only two values.

All data will probably be strings or cast as strings.

Thanks

Answer 1

I'd create an object which map your record and then create a collection of this object.

Answer 2

A custom class with 3 fields, and a java.util.List of that class.

There's no benefit in shoe-horning data into arrays in this case, you get no improvement in performance, and certainly no improvement in code maintainability.

Answer 3

If you need to access your data by key and by another key, then I would just use 2 maps for that and define a separate class to hold your record.

class Record {
   String field1;
   String field2;
   String field3;
}

and

   Map<String, Record> firstKeyMap = new HashMap<String, Record>();
   Map<String, Record> secondKeyMap = new HashMap<String, Record>();

Answer 4

This is another example of people writing FORTRAN in an object-oriented language.

Java's about objects. You'd be much better off if you started using objects to abstract your problem, hide details away from clients, and reduce coupling.

What sensible object, with meaningful behavior, do those three items represent? I'd start with that, and worry about the data structures and persistence later.

All data will probably be strings or cast as strings.

This is fine if they really are strings, but I'd encourage you to look deeper and see if you can do better.

For example, if you write an application that uses credit scores you might be tempted to persist it as a number column in a database. But you can benefit from looking at the problem harder and encapsulating that value into a CreditScore object. When you have that, you realize that you can add something like units ("FICO" versus "TransUnion"), scale (range from 0 to 850), and maybe some rich behavior (e.g., rules governing when to reorder the score). You encapsulate everything into a single object instead of scattering the logic for operating on credit scores all over your code base.

Start thinking less in terms of tables and columns and more about objects. Or switch languages. Python has the notion of tuples built in. Maybe that will work better for you.