OK great, thanks for the information Danny. I'm a bit concerned about the type safety issue (#1) not because I'm worried about the data being stored correctly, but because a conversion might have to be carried out many many time during an evaluation. I may be repeating the question here, but do you have any idea of how the above use case would work with 1M+ rows of data. Seems to me that converting some date text 2M+ times (twice per record in this case) would have an adverse effect on a query, no? Likewise converting when wanting to order a larger data set by date?
Really appreciate the feedback. Mark On Jan 14, 2008 8:12 PM, Danny Sokolsky <[EMAIL PROTECTED]> wrote: > Hi Mark, > > I will take a stab at your questions. > > 1) You do not need a schema to use typed data. A schema will make it so > Mark Logic treats an element or attribute as its defined type without an > explicit cast, but you can always add an explicit cast (like the > use-case example) to make sure XQuery treats a value as a certain type > (with or without a schema). The schema just makes that a little easier. > There might be some performance advantage to using a schema, but I don't > think it will be that big. It is worth trying though, as this might > depend somewhat on your content. The real performance advantage will > come from creating range indexes on elements or attributes you will use > in comparisons. Schemas can also help you ensure that your data is in > the correct format when you load it, as Mark Logic will throw an > exception if it cannot cast content in an element or attribute to the > type specified in the schema. > > 2) You could put the referencing information in the properties document. > The default conversion application in CPF does this, for example, to > keep track of the original documents and various converted documents. > > 3) There are no foreign key constraints built in. I think any best > practices would depend on what you are trying to do. Two approaches > that tend to work well are to a) put the constraining items in the same > document and/or b) use the properties document corresponding to a > document to store information about what is in the document. > > -Danny > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mark > Waschkowski > Sent: Monday, January 14, 2008 1:25 PM > To: [email protected] > Subject: [MarkLogic Dev General] Type safe data and referencing > questions > > Hi, > > Have been using Marklogic for a while now and haven't seen answers to > the below questions yet, anyone know of an answer or two? > > 1) Type safe data - I'm concerned with retrieval of typed data, > especially for date information. The only way to store typed data is > through the use of a schema right? I can't specify the type of data on > a per element basis, correct? ie. <person> <birthday > xs:date>01-01-1970</birthday></person> > > As well, I noticed the below query in the use case examples: > > let $item := doc("items.xml")//item_tuple > [end_date >= xs:date("1999-03-01") > and > end_date <= xs:date("1999-03-31")] > return > <item_count> > { > count($item) > } > </item_count> > > Is there a schema behind the loaded data or are the examples un-type > safe? Should I just not worry about type safety and convert the data > values to the type I need when querying? If so, won't that be a > performance issue? > > 2) Referencing - what is the (if there is one) best practice approach > to reference documents together? > ie. Document A and Document B should both refer to Document C > > 3) Foreign key constraints - is this supported at all in some fashion? > If not, any approaches to suggest? > > Thanks in advance for any and all suggestions! > > Mark > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
