The problem is as follows. Lets say I have a class Person which has the data property hasAge which points to an integer value. I would now like to anonymize a Person in a way that there would be like a class PersonANON so I could have for an individual Person1 a PersonANON1. The age of PersonANON1 should e.g. be rounded to the next multiple of five or in some other way transformed.
I thought about how to solve this. Creating PersonANON as an equivalent class to Person yields the same age which cannot be modified. I hoped in some way I could transform the data later on.
The only solution I came up with would be to have the two classes separate from each other and insert the data manually by externally querying the data, transforming it and creating a new individual with the fitting data in another query.
This does not seem very nice so I was hoping someone of you has a better idea. Maybe there is a way to leverage some ontology design feature that I am not aware of helping me.
Thanks in advance!
Related
I have an application which uses Parse to save objects on MongoDB. On my db, I have a class which has a column that should be a pointer to make my job easier. But I have a problem, this column should hold a pointer for differents classes. Parse doesn't allow me to do that because it takes the first pointer saved as the type of that column.
Does anyone have an idea about how I can work around this problem?
You can't have a pointer to two different classes in the same column. If you really need to do this, then you could create a new class that has fields for each of the possible pointer types.
So for example if you have a User and you need a pointer to either Car or Boat, then you could make a new class called Vehicle that has pointers to both Car and Boat. And then make the User just have one pointer to Vehicle.
That's a silly example, but it could technically work. How different are the classes that you need to point to from the same column? It's probably best practice if you consolidate them or find a different approach, but having a "holder" object that contains pointers to all possible values is one way you could essentially accomplish what you're trying to do.
So just getting started with Azure tables- haven't played with them before so wanted to check it out.
My understanding is that I should be thinking of this as object storage, rather than a database, which is cool. But I'm a bit confused on a couple points...
First, if I have one to many object relationships, what should the partitionkey of the root object look like? For example, let's say I have a University object, which is one to many to Student objects, and say Student objects are one to many to Classes. For a new student, should its partitionkey be 'universityId'? Or 'universityId + studentId'? I read in the msdn docs that the RowKey is supposed to be an id specific to the item I am adding, which also sounds like studentId.
And then would both the partitionkey and rowkey for a new University just be universityId?
I also read that Azure Tables are not for storing lists- I take it that does not refer to storing an object that contains a List...?
And anyone have any links to code samples using asp mvc 3 or 4 and razor with azure tables? This is my end goal, would be cool to see what someone who actually knows what they are doing does :)
Thanks!
You're definitely right that Azure Tables is closer to an object store than a database. You do have some ability to query on non-key columns, and to do logic in queries. But you shouldn't plan on using those features for anything performance critical.
Because queries are only fast if you specify at least a PartitionKey (and preferably a RowKey or range or RowKeys) that heavily influences how you lay out your tables. The decisions you make at the beginning will have big performance implications later. As a rough analogy, I like to think about them like a SQL Server table with the primary key as (PartitionKey + RowKey), that can never have another index. That's not completely accurate, but it'll get you thinking in the right direction.
First, if I have one to many object relationships, what should the partitionkey of the root object look like?
I would probably use the UniversityId as the PartitionKey. That's generally a safe place to start.
For a new student, should its partitionkey be 'universityId'? Or 'universityId + studentId'?
How do you plan to query the students? If you're always going to have their UniversityId & StudentId I would probably make them the PartitionKey and RowKey, respectively. If you're mostly going to query based on StudentId, I would use that as the PartitionKey instead.
would both the partitionkey and rowkey for a new University just be universityId?
That's a viable choice. You can also use a constant value (eg "UNIVERSITY") for the RowKey, if you've really got nothing else to put there.
I also read that Azure Tables are not for storing lists- I take it that does not refer to storing an object that contains a List...?
I'm not entirely sure what that means. Clearly you can store a collection of objects in a table, that's what they're for. You can't directly store a list in an entity property. So if your Student has a property of typee List, that can't be stored directly. But you could serialize it to XML or binary, and store that.
I don't have any code samples handy, unfortunately. This may be a good time to abstract your data logic into its own layer, rather than putting it in your MVC controllers. We've found that a well-abstracted data layer can make unit testing your logic very easy. If you create some interfaces for your tables, it's very easy to create mock objects using just a List and some LINQ.
I am working on a MVC3 code first web application and after I showed the first version to my bosses, they suggested they will need a 'spare' (spare like in something that's not yet defined and we will use it just in case we will need it) attribute in the Employee model.
My intention is to find a way to give them the ability to add as many attributes to the models as they will need. Obviously I don't want them to get their hands on the code and modify it, then deploy it again (I know I didn't mention about the database, that will be another problem). I want a solution that has the ability to add new attributes 'on the fly'.
Do any of you had similar requests and if you had what solution did you find/implement?
I haven't had such a request, but I can imagine a way to get what you want.
I assume you use the Entity Framework, because of your tag.
Let's say we have a class Employee that we want to be extendable. We can give this class a dictionary of strings where the key-type is string, too. Then you can easily add more properties to every employee.
For saving this structure to the database you would need two tables. One that holds the employees and one that holds the properties. Where the properties-table has a foreign-key targeting the employee-table.
Or as suggested in this Q&A (EF Code First - Map Dictionary or custom type as an nvarchar): you can save the contents of the dictionary as XML in one column of the employee table.
This is only one suggestion and it would be nice to know how you solved this.
I have a populated object from using the entity framework. Let's call it Order. The order has different properties such as Id, OrderDate, BillingAddress and so on. I need to let users update this data.
What's the best way to display this data in a form, while enforcing data annotations such as [Required]? I see MetadataType mentioned a lot, but I haven't seen how I can connect the dots with displaying the data as well.
One approach that I could take, but I'd like to avoid because of redundancy, is creating my own model object that has nearly identical properties. Then I would just need to basically just copy entity framework object A to new object B, where B has all my lovely data annotations. It just seems like there might be a better way.
Could anyone provide me with an example of a good way to accomplish this?
The "better way" is a big reason EF Code First is great. Otherwise, the only other way to do what you need is to do a mapping.
I'm about to embark on a project where a user will be able to create their own custom fields. MY QUESTION - what's the best approach for something like this?
Use case: we have medical records with attributes like first_name, last_name etc... However we also want a user to be able to log into their account and create custom fields. For instance they may want to create a field called 'second_phone' etc... They will then map their CRM to their fields within this app so they can import their data.
I'm thinking on creating tables like 'field_sets (has_many fields)', 'fields', 'field_values' etc...
This seems like it would be somewhat common hence why I thought I would first ask for opinions and/or existing examples.
This is where some modern schemaless databases can help you. My favourite is MongoDB. In short: you take whatever data you have and stuff a document with it. No hard thinking required.
If, however, you are in relational land, EAV is one of classic approaches.
I have also seen people do these things:
predefine some "optional" fields in the schema and use them if necessary.
serialize this optional data to string (using JSON, for example) and write it to text blob.