أفضل بنية بيانات Java لتخزين جدول Oracle 3 عمود؟ 3 صفيف العمود؟ أو الخريطة المزدوجة؟

Question

ما هو أفضل بنية بيانات لتخزين جدول Oracle الذي يبلغ حوالي 140 صفًا في 3 أعمدة. كنت أفكر في مجموعة متعددة الأبعاد.

بأفضل ما يرام ، لا أقصد بالضرورة أكثر كفاءة (لكنني سأشعر بالفضول لمعرفة آرائك) لأن البرنامج سيعمل كوظيفة مع متسع من الوقت للتشغيل ولكن لدي بعض القيود:

من الممكن أن تكون مفاتيح متعددة "لاغية" في البداية. لذلك قد يحتوي العمود الأول على قيم خالية متعددة. أحتاج أيضًا إلى أن أكون قادرًا على الوصول إلى العناصر من الأعمدة الأخرى. أي شيء أفضل من البحث الخطي للوصول إلى البيانات؟

مرة أخرى ، سيعمل شيء مثل [] [] [] .. ولكن هل هناك شيء مثل خريطة عمود 3 حيث يمكنني الوصول إلى المفتاح أو العمود الثاني؟ أعلم أن الخرائط لها قيمتان فقط.

من المحتمل أن تكون جميع البيانات سلاسل أو تم تصويرها كسلاسل.

شكرًا

Answer 1

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

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.

Answer 4

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