Hello,
I've got the following UML design :
C
|
A _____|______ B
So 2 objects A and B are connected through a relation C. (For example an
employment scheme : person A1 worked for company B1 at time C1, person
A1 worked for company B2 at time C2, person A2 worked for company B1 at
time C3, ...)
My current implementation exists of :
public class objectA { ... }
public class objectB { ... }
public class relationC {
private objectA A;
private objectB B;
// other things about the relation
}
I use a list with all relationCs in it. This takes not much memory but
if I want to check which objectB's are connected to an objectA or vice
versa, I need to check every relationC.
ArrayList result = new ArrayList();
foreach (relationC c in list)
{
if (c.getA().equals(A))
{
result.Add(c.getB())
}
}
Considering the fact I have about 10000 objectA's and 25 objectB's I can
have up to 250000 relationC's to check which makes my implementation
rather slow.
I considered adding direct links from A to B :
public class objectA {
private ArrayList objectBs
// ...
}
and the same the other way around but then the amount of memory used
goes up pretty fast.
I wonder if someone has an idea on how to make this faster without
needing a huge memory chunk.
TIA
Yves 3 1069
Cody,
Your system clock is off by one year.
--Bob
"cody" <pl*************************@gmx.de> wrote in message
news:OJ*************@TK2MSFTNGP12.phx.gbl... It is generally not useful to load *all* data contained in a database and then try to make *queries* against it. First, you have to consider what you want to do with the data.
If you want to display all companies where person A worked in, do a query
to return exactly that and display it. If you want to display all persons
that worked in a certain company query exactly that from the database and
display it. Do not worry to much about performance: Databases are designed just for that.
-- cody
On 2004-08-14, Yves Dhondt <no@privacy.net> wrote: Hello,
I've got the following UML design :
Sorry, but you ask design questions, you get long-winded answers... C | A _____|______ B
So 2 objects A and B are connected through a relation C. (For example an employment scheme : person A1 worked for company B1 at time C1, person A1 worked for company B2 at time C2, person A2 worked for company B1 at time C3, ...)
From a design standpoint, that just seems wrong to me. In the real
world, companies have employees and people have jobs. It's hard to be
definitive here without knowing what app you're writing, but it doesn't
seem natural to me to think in terms of time spans having
company-employee relationships.
That's how relational database think, of course, but relational
databases are pretty much antithetical to OOP design, and it's a mistake
to have the middle-tier mirror the relational design IMHO (I realize
this area of OOP design isn't really settled, of course, but that's my
opinion). My current implementation exists of :
public class objectA { ... } public class objectB { ... }
public class relationC { private objectA A; private objectB B;
// other things about the relation }
I use a list with all relationCs in it. This takes not much memory but if I want to check which objectB's are connected to an objectA or vice versa, I need to check every relationC.
ArrayList result = new ArrayList();
foreach (relationC c in list) { if (c.getA().equals(A)) { result.Add(c.getB()) } }
Considering the fact I have about 10000 objectA's and 25 objectB's I can have up to 250000 relationC's to check which makes my implementation rather slow.
OK, I just got flamed every which way in another thread for suggesting
this, but I'm stubborn. If a relationC object really is a key object in
your design, then groups of them shouldn't be gathering together in dumb
collections. They should belong to typed collection classes that can
answer reasonable domain-specific questions:
ArrayList results = list.GetBs(A);
Now you haven't solved the problem, but at least you've encapsulated the
search algorithm into a relationCCollection class, rather than having
the search logic spread out all over your code. At that point there's a
lot of implementation options that should come quite easily. You could
maintain an index of references to A's relations in a Hashtable, which
would make lookup very fast. If memory's the issue, you could implement
a load-on-demand scheme, where the relationCCollection pulls down the
records from the database when they're requested. You could implement a
lazy-load scheme, where records are pulled down when requested, but are
then kept in the collection.
What I'd probably try is lazy loading the records, then keeping them in
collections of WeakReferences, and then indexing the keys that were
important to me. But it depends on what exactly you're trying to
achieve. There's always a natural trade-off between memory and
performance, so where the balance should be depends on your application.
Basically, though, the trade-off comes down to this. If you want fast
lookup based on a key, you want a hash. If you want fast lookup based
on different keys, you need multiple hashes. If you don't have the
memory for multiple hashes, you need to offload the calculation (e.g.,
to the database).
Hi David,
This time, I understood what you are trying to say. (better coffee, more
sleep... :-)
I agree with what you said. You've clearly been thinking about this kind of
encapsulation for a while.
To Yves: you have a historical concept that is reminiscent of a data
warehouse: on a particular date, these two items were joined. Unfortunately
for you, data warehouses are large animals and require specialized
algorithms for searching and producing rolll-up calculations. You don't
make it clear what you are actually doing with this data, or even if the
employee-employer statement is just an example. However, David is right to
suggest that you should not try to mirror the logic of a database engine in
your middle layer. I hate to ask this, and I mean no disrespect, but are
you aware of SQL?
You are describing a simple many-to-many relation in a relational database.
Table A: Employees
Employee Id, Employee Name, etc
Table B: Companies
Company Id, Company Name, etc
Table C: EmployeeCompany
SomeUniqueKey -- GUID
EmployeeId
CompanyId
StartDate
EndDate
To find which Companies are connected to an Employee: (in Transact SQL)
Select Company.CompanyId, Company.CompanyName, EmployeeCompany.StartDate,
EmployeeCompany.EndDate
from Company inner join EmployeeCompany on Company.CompanyId =
EmployeeCompany.CompanyId
where EmployeeCompany.EmployeeId = @paramEmployeeId
Why not just program your "relation" object to perform the above query in
the constructor where you pass in an employee id (which is passed to TSQL in
@paramEmployeeId), place the results into your collection, and work from
there...
The only deviation I'd suggest from David's excellent post would be this:
cache the data if it is not likely to change and you are likely to need it
again. Otherwise, destroy the resultset the moment you've answered the
original question.
I hope this helps,
--- Nick
"David" <df*****@woofix.local.dom> wrote in message
news:slrnchtab4.ubf.df*****@woofix.local.dom... On 2004-08-14, Yves Dhondt <no@privacy.net> wrote: Hello,
I've got the following UML design :
Sorry, but you ask design questions, you get long-winded answers...
C | A _____|______ B
So 2 objects A and B are connected through a relation C. (For example an employment scheme : person A1 worked for company B1 at time C1, person A1 worked for company B2 at time C2, person A2 worked for company B1 at time C3, ...)
From a design standpoint, that just seems wrong to me. In the real world, companies have employees and people have jobs. It's hard to be definitive here without knowing what app you're writing, but it doesn't seem natural to me to think in terms of time spans having company-employee relationships.
That's how relational database think, of course, but relational databases are pretty much antithetical to OOP design, and it's a mistake to have the middle-tier mirror the relational design IMHO (I realize this area of OOP design isn't really settled, of course, but that's my opinion).
My current implementation exists of :
public class objectA { ... } public class objectB { ... }
public class relationC { private objectA A; private objectB B;
// other things about the relation }
I use a list with all relationCs in it. This takes not much memory but if I want to check which objectB's are connected to an objectA or vice versa, I need to check every relationC.
ArrayList result = new ArrayList();
foreach (relationC c in list) { if (c.getA().equals(A)) { result.Add(c.getB()) } }
Considering the fact I have about 10000 objectA's and 25 objectB's I can have up to 250000 relationC's to check which makes my implementation rather slow.
OK, I just got flamed every which way in another thread for suggesting this, but I'm stubborn. If a relationC object really is a key object in your design, then groups of them shouldn't be gathering together in dumb collections. They should belong to typed collection classes that can answer reasonable domain-specific questions:
ArrayList results = list.GetBs(A);
Now you haven't solved the problem, but at least you've encapsulated the search algorithm into a relationCCollection class, rather than having the search logic spread out all over your code. At that point there's a lot of implementation options that should come quite easily. You could maintain an index of references to A's relations in a Hashtable, which would make lookup very fast. If memory's the issue, you could implement a load-on-demand scheme, where the relationCCollection pulls down the records from the database when they're requested. You could implement a lazy-load scheme, where records are pulled down when requested, but are then kept in the collection.
What I'd probably try is lazy loading the records, then keeping them in collections of WeakReferences, and then indexing the keys that were important to me. But it depends on what exactly you're trying to achieve. There's always a natural trade-off between memory and performance, so where the balance should be depends on your application.
Basically, though, the trade-off comes down to this. If you want fast lookup based on a key, you want a hash. If you want fast lookup based on different keys, you need multiple hashes. If you don't have the memory for multiple hashes, you need to offload the calculation (e.g., to the database).
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jenniferyiu |
last post by:
IMHO, simply NO.
False actually, practically.
|
by: Patchwork |
last post by:
Hi Everyone,
I have a design related question (in C++) that I am hoping someone can help
me with. It is related to my previous post but since it was pointed out that
I was more or less asking...
|
by: Yves Dhondt |
last post by:
Hello,
I've got the following UML design :
C
|
A _____|______ B
So 2 objects A and B are connected through a relation C. (For example an
employment scheme : person A1 worked for company...
|
by: Code4u |
last post by:
I need to design data storage classes and operators for an image
processing system that must support a range of basic data types of
different lengths i.e. float, int, char, double. I have a...
|
by: Christoph Zwerschke |
last post by:
Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.
For instance, I just wanted to use the index() method on a tuple which
does...
|
by: Peter M. |
last post by:
Hi all,
I'm currently designing an n-tier application and have some doubts about my
design.
I have created a Data Access layer which connects to the database (SQL
Server) and performs Select,...
|
by: Krivenok Dmitry |
last post by:
Hello All!
I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer....
|
by: neelsmail |
last post by:
Hi,
I have been working on C++ for some time now, and I think I have a
flair for design (which just might be only my imagination over-
stretched.. :) ). So, I tried to find a design...
|
by: arnaudk |
last post by:
I am trying to come up with a class design to deal with asynchronous data to be stored and analyzed over multiple time frames and could really use some design input. This is a rather long question...
|
by: Pallav singh |
last post by:
Hi ,
when should i select Factory Method / Prototype Design Pattern
during my design phase ??
as both look similar to me
Thanks in Advance
Thanks
Pallav
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| |