The advent of the family of *edEntityClass functions in V12 looks very promising. Dataset and its related queries are ideal for initial exploration and rapid prototyping but with this new functionality, transiting to the Entityframework seems more apt when eying off scalable, relational-database-type implementations. It is straightforward to perform this conversion simply, say by assigning integer-named Entities to essentially act as primary keys to a Dataset's rows ... e.g.

convertToEntityStore[type_, dataset_Dataset] :=
  With[{entities = Module[{x = 1},
      Association @@ Query[All, (ToString[x++] -> #) &]@dataset // 
   EntityStore[type -> <|"Entities" -> entities|>]];

store = convertToEntityStore["titanicByEntities", ExampleData[{"Dataset", "Titanic"}]]

enter image description here

... but are there other things to consider as part of good, scalable practice? For example, should further typing take place and/or other properties/classes added? Is cloud-based delivery using EntityStore the way to go or does there come a point where it makes more sense to convert further into traditional databases and if so, at what point does this occur?

  • $\begingroup$ I mean one thing to consider is that just assigning a numeric index is probably counter to what you're trying to represent. Keys should generally provide some basic info about the entity they label. $\endgroup$ – b3m2a1 Jun 30 at 22:13
  • $\begingroup$ @b3m2a1 I'm not so sure in this case. The definition of this key in the WDF is the CanonicalName which here would appear to be most naturally the passenger's name. Short of knowing these names however, stringed integers seem an apt default. In the "office rdb" documented example, the tables have a melange of CanonicalNames as per rdb = RelationalDatabase[ FindFile["ExampleData/ecommerce-database.sqlite"]]; EntityRegister[EntityStore[rdb]];(EntityList[#] // Shallow) & /@ rdb["Tables"] including a few that involve sequential/non-sequential integers ... $\endgroup$ – Ronald Monson Jul 1 at 1:52
  • $\begingroup$ ... Certainly if you are going to be working with these entities individually you'd want something a bit more expressive but this can also be achieved via "Label" (say here something like "TitanticPassenger12"). $\endgroup$ – Ronald Monson Jul 1 at 1:53
  • $\begingroup$ Well yes you did say "generally". The other relevant issue is going to be how the the database/entitystore is going to change over time. It seems unlikely that more passengers will be added to this list of titanic passengers but in general "more unique" keys may be more appropriate. $\endgroup$ – Ronald Monson Jul 1 at 2:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.