Thank you, very interesting. On Monday, February 9, 2015 at 12:28:41 AM UTC+1, Lvc@ wrote: > > Hash indexes can be O(1) in the best case, so I'd say between O(logN) and > O(1). However direct access is always faster, even than Hash index when > it's O(1). > > Lvc@ > > ᐧ > > On 8 February 2015 at 22:12, Riccardo Tasso <[email protected] > <javascript:>> wrote: > >> Aren't hash indexes O(1)? >> >> Riccardo >> Il 08/feb/2015 21:08 "Luca Garulli" <[email protected] <javascript:>> ha >> scritto: >> >> Hi Rasmus, >>> Indexes tend to be O(LogN), while RID is O(1). So it will always be >>> faster. >>> >>> Lvc@ >>> >>> ᐧ >>> >>> On 8 February 2015 at 11:39, Rasmus Eneman <[email protected] >>> <javascript:>> wrote: >>> >>>> Luca, bu using slugs in your URLs instead of database IDs you >>>> completely remove this problem, as well as making your urls nicer and >>>> better for SEO. >>>> >>>> A question for people with good experience with OrientDB, what is the >>>> performance implications with using slugs over rids if the slugs are >>>> indexed? >>>> Should I take care to keep a slug to rid mapping in for example redis >>>> so that queries to OrientDB always uses rids? >>>> >>>> >>>> On Wednesday, January 28, 2015 at 12:43:21 AM UTC+1, JR wrote: >>>>> >>>>> Thanks Riccardo, >>>>> >>>>> good point! do you know how others are solving this problem? I'm >>>>> planning to use OrientDB as my only storage solution. >>>>> >>>>> Thanks a lot, >>>>> Luca >>>>> >>>>> On Tuesday, January 27, 2015 at 3:39:54 PM UTC-8, Riccardo Tasso wrote: >>>>>> >>>>>> Yes Luca, >>>>>> >>>>>> consider also if you use rids in your URLs. For example: >>>>>> http://myapp.com/details.jsp?rid=1:1 >>>>>> >>>>>> In this case if someone links to your URLs it could be a problem. >>>>>> >>>>>> Cheers, >>>>>> Riccardo >>>>>> Il 27/gen/2015 21:29 "Luca Rondanini" <[email protected]> ha >>>>>> scritto: >>>>>> >>>>>>> Hi Andrey, >>>>>>> >>>>>>> just to double check, if I use RIDs in my web app everything should >>>>>>> be fine. Inserts/updates won't change any RIDs. Problems may raise if, >>>>>>> for >>>>>>> example, I'm storing RIDs in MySQL as reference. If then, I export and >>>>>>> reimport the data in orientDB the RIDs may be changed and the MySQL >>>>>>> data >>>>>>> won't reference the right rows anymore. >>>>>>> >>>>>>> Can you confirm? >>>>>>> >>>>>>> Thanks, >>>>>>> Luca >>>>>>> >>>>>>> On Monday, January 19, 2015 at 5:28:16 AM UTC-8, Andrey Lomakin >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Bertran, >>>>>>>> The only issue is that if you do export database to JSON and then >>>>>>>> back your RIDs will be changed. >>>>>>>> But may be we will add option to keep rids on their places. Not so >>>>>>>> hard to do. >>>>>>>> The only downside of such flag will be presence of holes for rids >>>>>>>> of removed records. >>>>>>>> Each record removal consumes about 10 bytes of disk space (not so >>>>>>>> much )) ), but when you do export/import we optimize space is used by >>>>>>>> database as result rids may be changed. >>>>>>>> >>>>>>>> On Mon, Jan 19, 2015 at 2:48 PM, Bertrand Quenin < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm currently using OrientDB for a project at work and I have some >>>>>>>>> question about record IDs. >>>>>>>>> >>>>>>>>> As far as I understood, record IDs are unique and can be used to >>>>>>>>> to identify a record in a deterministic way. I was wondering if these >>>>>>>>> IDs >>>>>>>>> can be used to identify objects through (REST) APIs. >>>>>>>>> >>>>>>>>> As any web application, I need to identify objects one way or >>>>>>>>> another and I was wondering what the best approach would be: >>>>>>>>> 1/ Using record IDs provided by orient DB >>>>>>>>> 2/ Adding a "business" id field to my objects and manage it aside. >>>>>>>>> >>>>>>>>> So far, I didn't see any reason why I shouldn't use the record ID >>>>>>>>> itself, the only con I see is that RID are strings clusterId#position >>>>>>>>> (and >>>>>>>>> not plain integers) and it's a bit harder to expose in an URL ... >>>>>>>>> >>>>>>>>> Is there any issue I haven't foresee ? >>>>>>>>> >>>>>>>>> Thanks for your help >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> --- >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Andrey Lomakin. >>>>>>>> >>>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> 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] <javascript:>. >>>> 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] <javascript:>. >>> 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] <javascript:>. >> 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.
