I know I can enforce maximum policy by That example seems wrong. Each row in that table is a relationship between a user and a category, it is a junction table (sometimes called a relationship table). The count is not a property of the relationship but of the user so that should be in the user table. What if someone deletes the row where count=2? You'd need to enforce the update of those with count>2, perhaps with a trigger, but this would be problematically complex compared to using a trigger or computed column to update a count in the user table. Back to the original question: How can I enforce a policy which ensures each users has at least 3 categories and at most 5 categories. If you keep the count in the User table then you should be able to define a constraint something like category_count BETWEEN 3 AND 5 OR category_count = 0 - the extra check for zero categories being there to deal with new User rows that can not yet have categories listed in the junction table (because listing the relationships there before the user row exists would be a foreign key violation). If you update the count via trigger rather than computed column then I'd instead not have the count but just do the calculation in the trigger and raise an error if the value is not correct. In either case you still have to address in your application making sure that a user gets the minimum set when their row in the user table is created, you are not going to be able to enforce that in the database. Also you need to make sure the first 3 (or whatever your minimum is) are all created in the same statement or the checks will fail when the first on is added (and it must be the same statement not just the same transaction, triggers, computed columns, and check constrains will be run per statement not per transaction).

Unique constraint indexes do not allow included columns. You need to create a regular unique nonclustered index instead to include columns. That said, it is not necessary to include those columns because they are the clustered index key. The clustered index key is implicitly included in all non-clustered index leaf nodes for use as the row locator. The only reason you see a key lookup in the plan is because of SELECT *, which requires CreateDate in addition the other columns of interest. Yet another reason to avoid it.

As you wrote "but I'm curious if there's a specific solution for other flavours of SQL" This would be possible in Postgres using an https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-EXCLUSION alter table tires add constraint single_tire exclude using gist (car_id with =, tire_id with <>); So the first combination of (car_id, tire_id) will then constrain all subsequent ones. If there is a row with (1,1,x), inserting another row with (1,1,y) will work, but inserting (1,2,y) will not.

That's just a question of syntax. A column constraint is defined like CREATE TABLE ... ( col type [CONSTRAINT name] constraint_definition, ... ); while a table constraint look like CREATE TABLE ... ( col type, [CONSTRAINT name] constraint_definition, ... ); The resulting constraint is the same in both cases. So the documentation is saying that you need to write NOT NULL in the column definition and you cannot write it anywhere else.

Yes, you can use an https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-EXCLUSION . You'll need to install the additional module https://www.postgresql.org/docs/current/static/btree-gist.html to add an operator class we need for the multicolumn index backing the constraint. There is no data type "datetime" like you display. Your values indicate date, so I'll go with that. (The actual data type matters for the implementation!) Also, your table design with just valid_from generally works. valid_to can be derived from the next row. But for the purpose of an exclusion constraint, we need valid_to in the same row. So add that (redundantly). ALTER TABLE person_email ADD CONSTRAINT person_email_no_username_overlap EXCLUDE USING gist (username WITH =, daterange(valid_from, valid_to, '[]') WITH &&); This way, the same username can never be in use in overlapping time ranges. Note how I made upper and lower bound inclusive with '[]'. Adapt to your needs. There are subtle differences for different data types. NULL as lower or upper bound means "unbounded". Alternatively, you could use a daterange column to begin with. Either has pros and cons. Related: https://stackoverflow.com/a/56690941/939860 https://stackoverflow.com/a/67612325/939860 https://stackoverflow.com/a/15305292/939860 https://dba.stackexchange.com/questions/193688/composite-constraint-of-numrange-and-boolean/193691#193691

I'd be interested in the number of total rows you have in your Parts.ManufacturingData table and what the total runtime currently is for your query. Does the number of rows the execution plan says it's returning (roughly 32 million) actually make sense for your query? Maybe you'll find a filtered index saves you a little bit of time since it'll pre-materialize only the data you want. How about an index with this definition, does it make any difference? CREATE NONCLUSTERED INDEX IX_ManufacfuringData_MSLID_Filtered ON Parts.ManufacturingData (MSLID) WHERE MSLID IS NOT NULL; Note you shouldn't need to do anything different to your query to use the above filtered index once it's created. But you should check the execution plan to ensure the optimizer chose this new index over any other indexes on your table when the query runs. If that doesn't make any difference, the other thing you can try is adding the https://www.mssqltips.com/sqlservertip/3296/why-the-sql-server-forcescan-hint-exists/ hint to your query like so: select partid,mslid into ExtractReports.dbo.manufactureparts from parts.manufacturingdata m with(nolock, FORCESCAN) where mslid is not null This would tell the optimizer to use a scan operation instead of seek against your data. This would generally be more performant if roughly a majority of your data in the table meets the criteria of your WHERE clause. I.e. it's generally faster to scan the entire table at that point and filter out the unwanted rows, than to seek against so many rows. But hard to say if this'll help your circumstances without knowing your data or testing it. Please note https://docs.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-table?view=sql-server-ver15 should be used cautiously and only in circumstances where alternative optimization methods are not possible. Some query hints limit the number of available execution plans that the optimizer can choose from, and therefore can result in an error being thrown when certain queries using those hints try to execute. In this case, I think using the FORCESCAN hint is likely ok, as your query is simple, and I don't believe it limits the number of query plans as much as other hints do.

Unique constrains, like any other index, can convert multiple columns in the same table - so to achieve what I think you are asking for you need to create a unique constraint on userId, repoId. This will enforce no user having multiple repos with the same identifier but will not stop another user having a record with the same repoId as one of mine. The syntax for that would be something like ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE (userId, repoId); Or you could create a unique index instead which is functionally identical. See https://dba.stackexchange.com/questions/144/when-should-i-use-a-unique-constraint-instead-of-a-unique-index for more discussion about that similarity and when you might choose one over the other. Note: It might be a good idea to flesh out you question to describe what you are modelling in more detail, and what structure you currently have. It may be that a many-to-many relationship via a junction table is more appropriate, but I'll not dive deeply into that as it might easily be rendered completely irrelevant upon knowing more about your goal.

The clause CONSTRAINT is used to name this restriction of integrity. Only this, give a name of your choice.Even without it will still be a restriction imposed on the table, but the name will be the same of the associated index in FOREIGN KEY, and in case you do not have an indicated index it creates a name based on the column name. In this case you do not have this index without CONSTRAINT the name would be generated from the column. In your example the name of these restrictions will be pk_id_socio, un_socio_cpf, socio_id_situacao_fk_ref. https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html .

Try to reverse the delete order, first the recipient and then the source, or vice versa.Type ALTER TABLE `origem` ADD CONSTRAINT `destino_ibfk_1` FOREIGN KEY (`destino_id`) REFERENCES `destino` (`destino_id`); Or it goes the easy side, but it is not a correct solution. Disconnect keycheckSET FOREIGN_KEY_CHECKS=0; -- desliga SET FOREIGN_KEY_CHECKS=1; -- religa

Hi.ALTER TABLE `banco`.`tabela` MODIFY COLUMN `id` int(11) NOT NULL AUTO_INCREMENT FIRST;

What you want is this command:ALTER TABLE macaco ADD CONSTRAINT id_macaco_pk PRIMARY KEY (id); http://sqlfiddle.com/#!17/a3e98

Your table chamado has the following primary key definition:PRIMARY KEY("chamado_id","empresa_cliente_empresa_id","usuario_solicitante","usuario_responsavel") And nothing else. This means that a call will only be considered "duplicated" if all these fields are the same. Example:chamado_id empresa_cliente_empresa_id usuario_solicitante usuario_responsavel 1 1 1 2 1 1 1 3 1 1 2 3 ... All of these would be valid records according to their primary key definition.Now see how you create a foreign key to the table chamado:REFERENCES "chamado"("chamado_id", "empresa_cliente_empresa_id") Now, if there can be multiple fields with value chamado_id equal and equal empresa_cliente_empresa_id equal - as long as the rest is different - how to know which of is being referenced? Only if the bank knows it exists a single line with this set of values, i.e. if they are subject to a restriction unique.To solve this problem, is enough add a restriction unique to the table called containing these two columns. But most likely what you want is not this: review the way you define the primary table key chamado, is it even possible to have several of these columns repeated? In fact, it is even possible to have two calls with the same chamado_id? Adjust your primary key definition accordingly, and the problem will disappear alone (since a primary key also establishes a restriction unique).

The error is in creating the tables as you put in the comments:CREATE TABLE minsarh.tb_ds_pergunta ( id_ds_pergunta int(11) unsigned NOT NULL AUTO_INCREMENT , ds_pergunta varchar(255) NOT NULL , PRIMARY KEY (id_ds_pergunta) ); CREATE TABLE perguntas ( id_pergunta int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (id_pergunta), Alter Table minsarh.perguntas add CONSTRAINT fk_perguntas_perg FOREIGN KEY (id_ds_pergunta) REFERENCES tb_ds_pergunta (id_ds_pergunta) ON DELETE NO ACTION ON UPDATE NO ACTION; I don't know you didn't put all the creation but it's missing to close CREATE TABLE before starting ALTER TABLEIn addition the types and sizes of the PK and FK should be equal in the first table is defined as INT(11) and the other INT(10)You're also trying to use a PK from a table like FK from the same table, that doesn't even make senseGenerally FK are not AUTO-INCREMENT

Hello. I tried this and it worked out:alter table usuario add unique(login);

Yes, the contraints are part of that category. They are used in creating the tables to ensure rules on the fields you are creating, an example is key primaria or null support.

You need to use it FK the same number of columns as in PK. In this case, you have one PK composed of [ID_PDR],[CD_PODER] yours FK also needs 2 columns of the same type of data.I hope it helps you.I tried your script and added this column ID_PDR to table [TB_GRUPOS_PODERES_PODERES]CREATE TABLE [dbo].[TB_PODERES]( [ID_PDR] [int] IDENTITY(1,1) NOT NULL, [CD_PODER] [char](10) NOT NULL, [NM_PODER] [varchar](100) NOT NULL, [IC_ATIVO] [bit] NOT NULL, [DT_ULT_ATUALIZACAO] [datetime] NOT NULL, CONSTRAINT [PK_TB_PODERES_PODER] PRIMARY KEY NONCLUSTERED ( [ID_PDR] ASC, [CD_PODER] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] CREATE TABLE [dbo].[TB_GRUPOS_PODERES_PODERES]( [ID_GPP] BIGINT IDENTITY(1,1) NOT NULL, [ID_GRP_PDR] [bigint] NOT NULL, [CD_PODER] char NOT NULL, [IC_ATIVO] [bit] NOT NULL, [DT_ULT_ATUALIZACAO] [datetime] NOT NULL, [ID_PDR] [int], PRIMARY KEY CLUSTERED ( [ID_GPP],[ID_GRP_PDR],[CD_PODER] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] ALTER TABLE [dbo].TB_GRUPOS_PODERES_PODERES WITH CHECK ADD CONSTRAINT FK_TB_GRUPOS_PODERES_PODERES_TB_PODERES FOREIGN KEY([ID_PDR],[CD_PODER]) REFERENCES [dbo].TB_PODERES ([ID_PDR],[CD_PODER]) GO ALTER TABLE [dbo].TB_GRUPOS_PODERES_PODERES CHECK CONSTRAINT FK_TB_GRUPOS_PODERES_PODERES_TB_PODERES GO

ResolvedI just stored the class PxJoint rather than PxFixedJoint. How PxJoint is an abstract class, I can convert to PxFixedJoint whenever I want.

CREATE UNIQUE INDEX IpEmail ON tabela (ip ASC, email ASC) https://docs.microsoft.com/en-us/sql/t-sql/statements/create-index-transact-sql?WT.mc_id=DOP-MVP-5002397 .I hope you have another column that is primary, these data may vary and are not good primary key candidates. If you want to insist:ALTER TABLE tabela ADD CONSTRAINT IpEmail PRIMARY KEY CLUSTERED (ip, email); https://docs.microsoft.com/en-us/sql/relational-databases/tables/create-primary-keys?WT.mc_id=DOP-MVP-5002397 . https://github.com/maniero/SOpt/blob/master/SQL/Create/NewIndex.sql .

RESOLVEDWell, after searching a lot, I ended up finding a solution in the documentation itself of PhysX.What I did was "parent" (make "son") the object I wanted (which in the case is static) to a rigidbody object (object affected by physics) multiplying the transformation of the "father" object by the "son" object.Then I used the method http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/classPxRigidActor.html#17c7ab7d692e4b3b8239216aa0d6eeb7 to add the physical shape of the "son" the list of physical shapes of the "father" and, http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/classPxRigidBodyExt.html#b8f6af57a0fde875c41e5d747dec49fb .// C++ // Acada frame ("Parentando") m_FilhoWorldTransform = m_pPai->getWorldTransform() * m_FilhoWorldTransform; // ... // Adicionando shape "filho" ao rigidbody "Pai" m_pPai->getRigidBody()->attachShape(m_Filho->getShape()); // ... // Atualizando massa e inércia physx::PxU32 mass_count = 2; // Numero de shapes/massas physx::PxReal* masses = new physx::PxReal[2]; masses[0] = pai_mass; masses[1] = filho_mass; physx::PxRigidBodyExt::setMassAndUpdateInertia(*parent->getRigidDynamic(), masses, mass_count); delete masses; And see the result. There's no more barter. Physics works properly, it's as if the cubes were part of the "Father" object.

You can disable constraint verification through a ALTER TABLE :ALTER TABLE tabela DISABLE CONSTRAINT nome_da_constraint; However be aware that this can cause duplicity problems in your table if you do not ruin constraint.