Ah, ok, I didn't understand. In OrientDB the word "link" is commonly used
to refer a document field that refers to another document.
So OK for graph model :)

I have a couple of questions about your code:
1) what kind of graph connection are you using (remote, plocal, memory)?
2) have you tried putting some commit operations during loops, let's say
every 1000 edge creations?
3) have you tried declaring MassiveInsert intent?

Luigi


2014-10-22 18:23 GMT+02:00 BojanV <[email protected]>:

> Regarding LINKLIST or LINKSET, isn't it for document model? I would prefer
> to use graph model. And regarding of creating of edges (or links), when I
> migrate stored procedure one by one, and when I find join expression that I
> didn't have before, I guess I need than to create edges (links) to that
> vertices? And so over and over, when I want to migrate join expression I
> have to create new edges?
>
> My import code:
>
> Map<Integer, Vertex> bookMap = new HashMap<>();
>         String queryString = "SELECT * FROM Books";
>         Statement statement = connection.createStatement();
>         ResultSet rs = statement.executeQuery(
> queryString);
>         while (rs.next()) {
>             Vertex bookVertex = graph.addVertex("class:Book");
>             Integer bookId  = rs.getInt(1);
>             bookVertex.setProperty(...);
>             // fill vertex from result set
>             bookMap.put(bookId, bookVertex);
>         }
>         rs.close();
>         statement.close();
>
>         Map<Integer, Vertex> authorMap = new HashMap<>();
>         queryString = "SELECT * FROM Authors";
>         statement = connection.createStatement();
>         rs = statement.executeQuery(queryString);
>         while (rs.next()) {
>             Vertex authorVertex = graph.addVertex("class:Author");
>             Integer authorId  = rs.getInt(1);
>             authorVertex.setProperty(...);
>             // fill vertex from result set
>             authorMap.put(authorId, authorVertex);
>         }
>         rs.close();
>         statement.close();
>
>
>         graph.commit();
>
>         queryString = "SELECT * FROM BookAuthor";
>         statement = connection.createStatement();
>         rs = statement.executeQuery(queryString);
>
>
>         while (rs.next()) {
>
>             Integer bookId = rs.getInt(2);
>             Integer authorId = rs.getInt(2);
>
>             Edge edge = graph.addEdge(null, bookMap.get(bookId),
> authorMap.get(authorId), "BookAuthor");
>             edge.setProperty(....);
>         }
>         rs.close();
>         statement.close();
>
>         graph.commit();
>
>
> I used both OrientGraph and OrientGraphNoTx but I didn't see a big
> difference
>
>
>
>
> On Wednesday, 22 October 2014 16:39:33 UTC+2, Luigi Dell'Aquila wrote:
>>
>> Hi Bojan
>>
>> in general IMHO all this makes sense.
>> I guess edge creation speed can be improved with some tuning or code
>> tricks, but I should see your import code..
>> Anyway, if you decided to go with links and you need 1:n or n:n, you can
>> use LINKLIST or LINKSET properties instead.
>>
>> About procedure translation
>> 1) if you want to use Gremlin you need a graph structure (so edges), if
>> you decide to go with links you have to use OrientDB SQL or Javascript
>> functions
>> 2) I'm afraid you have to do it manually...
>>
>> Luigi
>>
>>
>>
>> 2014-10-22 11:33 GMT+02:00 BojanV <[email protected]>:
>>
>>> Hi guys!
>>>
>>> I was given a task to check could we migrate our document management
>>> database to OriendDB. So far I was playing with OriendDB, gremlin so see
>>> how it works.
>>> My question is should we move it at all, could all things that we can do
>>> now in rdbms be done in graph database?
>>> The main reason we are investigating this is: some stored procedures
>>> take too long to execute (because we have lots of data).
>>>
>>> Our db model has many tables, some of them are just connecting tables
>>> (n:n relationship), but they all have one thing in common: no foreign keys!
>>> When we query the data we use case numbers, document numbers and another
>>> "numbers" to connect data. These numbers sometimes are not unique per table
>>> (we have 'deleted' or 'active' columns that we use in our queries).
>>> I managed to import some data, it went ok, importing of edges was
>>> extremely slow, so instead of that I tried to create links between classes
>>> but it failed because of this "uniqueness reason".
>>>
>>> And stored procedure that I have to "translate" to gremlin uses joins
>>> heavily (and it has about 150 lines of code). Since I can not create links,
>>> creation of edges lasts too long, how to use gremlin to traverse data at
>>> all?
>>> And let's say that I create edges and links somehow so I can translate
>>> my stored procedure, what should I do when I have to translate new stored
>>> procedure which uses totally different join expressions?
>>>
>>> My question is should all these make sense?
>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OrientDB" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to