I have this DB structure:
Is there a way to add constraint additionally and explicit to a certain attribute (column) of the table pqs ? For example to bdm ?
Or to define the relevant attribute or to define a connection to the relevant attribute in pqs somehow ?
I have one model, Target, which has a property/field called targetName. I have a second model, Operation, with a field verb. Both these models have a primaryKey field named id.
I have a third model, Policy, that is a defined association/join with additional properties; Policy also contains targetName and verb fields. How do I specify in the belongsToMany() for Target and Operation to use the fields above, instead of defaulting to the id field? I know of the through option to specify the actual model. What's in the ellipsis section below?
Target.belongsToMany(Operation, {through: Policy, ...});
and
Operation.belongsToMany(Target, {through: Policy, ...});
Also, do I just specify the two belongsToMany()?
There is no way to do foreign keys pointing to non-primary keys in sequelize. See https://github.com/sequelize/sequelize/issues/2967
I'm trying to design a database model for the following scenario:
a person can have a bunch of "attributes" describing him or her, each with a number of predefined "values" to choose from. An example of attribute could be 'eyes' with the possible values of 'hazel', 'blue' and 'green'. Or 'hair length' with 'very long', 'long', 'medium', 'short', 'very short', 'none' (yes, I know real life has more variety than this but let's keep it simple),
I came up with the following model:
UNIQUE constraint on person_id, attribute_id pair in person_has_attribute_value table makes sure there is no more than exactly one value for a given attribute per person. I also want to be able to add / remove / modify the attributes as well as their possible values without messing up data integrity, so all relationships have CASCADE on update and delete.
This should work fairly well, but:
1. Let's say for some attributes I want to be able to assign multiple values to a person. Is there a way to enforce uniqueness of person_id, attribute_id only for some values of attribute_id (preferably based on an additional multiple BOOLEAN column in the attribute table) or do I need a completely different set of tables for such cases?
2. Let's say some attributes don't have predefined values and can take arbitrary numerical values instead (e.g.: height or weight). Is there a way to somehow incorporate those in the existing structure while keeping the constraints on those attributes that do have predefined values, or do I need yet another set of tables for such cases?
To start with: I like your data model so far.
As to point 2: You can use the same data model, if you want so. If for an attribute 'height [cm]' you need the value 182, you can create a record in attribute_value with that value and use this. However, as you want to use another input method (typing in a value instead of choosing a value from a list), you need a flag in attribute to tell you whether an attribute is a fixed list attribute or a free variable attribute.
As to point 1: This is more difficult, because this goes against your constraint. On first glance you have two options here:
Drop that constraint. Well, so you could suddenly have a person with two different eyes (and wow, you could even store David Bowie in your database then) or with two different heights, which you probably don't want. You would have to trust your programs and yourself to be careful about this, because the dbms would no longer help you regarding this.
Use new tables for this.
However, as there are three types of attributes then (single fixed, multiple fixed, single variable) we could introduce this as a main key in your database (primary keys bold):
attribute_type (att_type, description) -> SINGLE_FIXED, MULTI_FIXED, SINGLE_VAR
attibute (att_type, att_no, description) -> EYES=SINGLE_FIXED, HEIGHT=SINGLE_VAR, NATIONALITY=MULTI_FIXED...
attribute_value (att_type, att_no, value, description) -> Eyes=SINGLE_FIXED=hazel ...
person_has_attribute_value (person_id, att_type, att_no, value) -> Person1=Eyes=SINGLE_FIXED=hazel, Person1=Nationality=MULTI_FIXED=British, Person1=NATIONALITY=MULTI_FIXED=German, ...
Depending on the dbms you could now check conditionally for uniqueness.
In PostgreSQL for example:
CREATE UNIQUE INDEX idx_unique_for_single_types ON person_has_attribute_value (person_id, att_type, att_no)
WHERE att_type IN ('SINGLE_FIXED','SINGLE_VAR');
Note, not all dbms offer a way to check for conditional uniqueness. In some you may need computed columns or triggers or function indexes, in others such options may not be available. I must admit, I don't know if it is possible in MySQL.
So it depends on the dbms if this different data model helps. Maybe you should keep it simple and just stick to what you have, add the attribute type to attribute for determining the input method and drop the unique constraint.
The documentation for inaport states you can just map lookup fields and it will work out what types they are.
I am mapping from CRM 4 to CRM 2011 (using the CRM Connectors), however all my lookups fail with
A lookup value was mapped to account.{field name} but no target entity name was supplied and no default is available.
I have to fall back to adding a custom field, checking if their is a lookup id in the field, and then making a lookup value as per the documentation of guid::entityname using expressions which is painful.
Is this feature working for anyone else? Do i need to set up a child-parent relationship? I only ever add a map for the entity I'm working on.
Inaport will try to work out what the correct entity reference is and default it. For example, if the lookup is the foreign key in a child table, the entity reference will default to the parent.
There are some circumstances where a lookup may reference multiple entity types, and Inaport cannot infer the correct type. For example, and activity "regarding" lookup may reference 12 different entity types.
It could do a better job when a custom lookup is only referencing a single entity type, and a change request has been put into the system.
As you noted, when Inaport does not correctly infer the entity type you can force it by appending "::entityname" to the GUID you are mapping to the lookup field. This is discussed in more detail in the help.
HTH
Regards
David Evans
I've been using a custom base class with an id property that is automatically assigned by a manager class when an instance is created. I use this value in multiple ways and require it to differentiate each instance.
I want to remove the need for my own base class but still have a way to tell instances throughout my application apart.
Is there a property set on all objects in ActionScript 3 that can act as a unique identifier?
Nope, there aren't any built-in unique IDs like this. What you're doing sounds like the right way to go if you need to track objects. (You can differentiate objects with the === operator - that is, you can tell whether two references point to the same object or not. But I gather that's not all you need.)