New answers tagged

0

If you lump all the column_## columns into a JSON field, you can have a limit of 4GB. The question of how much gets complicated. InnoDB has 4 ROW_FORMATs: REDUNDANT, COMPACT, DYNAMIC, COMPRESSED. I think you could have 400 columns of VARCHAR(255) or TEXT (or ...) in ROW_FORMAT=DYNAMIC. That format uses a 20-byte pointer in the record to where the actual ...


-1

I found this link useful reference; https://www.percona.com/blog/2011/04/25/performance-schema-overhead/


1

Migrating the Data is a Job in itself Keeping Data in sync is a job is yet another job. Creating a new front end is yet another job. there's lots of ways to tackle the problem. there's a lot that can go wrong with data migrations, so if you've never done one before unless the business is yelling for it I'd move very slowly and carefully. 1st I'd ...


0

A schema is a collection of named objects classified logically in the database. In a database, you cannot create multiple database objects with same name. To do so, the schema provides a group environment. You can create multiple schemas in a database and you can create multiple database objects with same name, with different schema groups. A schema can ...


0

DROP SCHEMA would attempt obtaining exclusive use of the schema first, so it would only actually manage to drop the schema when PostgreSQL is done retrieving data from ongoing queries. Further queries would likely be locked until the end of the transaction in your question. Queries accessing tables in the prod schema may fail after this transaction is ...


0

A possibly simple way is replacing all MS-Access tables with links to views in your SQL Server with the exact same structure as the old Access tables. If the views are simple enough (e.g. a select statement from a single table with a primary key and unmodified columns -other than renaming them-) they'll be directly updatable, otherwise you can use updatable ...


1

Let's do the math. 6500 characters, even in CHARACTER SET utf8mb4 takes no more than 26000 bytes. TEXT has a limit of 64K bytes and needs a hidden 2-byte length field. LONGTEXT has a 4-byte length field. Let's say (for the 'math') that the average row length, including this text, is 3000 bytes. Math... Savings of switching from LONGTEXT to TEXT: 2 ...


1

It is best to store your tags in a separate table because of the many to many relationship. With something like tagging images you can end up with a very large number of comma separated values that would need to be parsed any time you search your database which will lead to massive performance problems as your data grows. Going that route and searching for ...


1

What build of 2008 r2? Have you looked at this connect? https://connect.microsoft.com/SQLServer/feedback/details/672153/the-ole-db-provider-sqlncli10-for-linked-server-x-reported-a-change-in-schema-version-between-compile-time-and-run-time Have you tried the workaround listed? Workaround (From above connect): I solved my problem with DBCC ...


0

I do not think it will be worthwhile to change the type. You may save a byte or two for the length field of each column value if using TEXT or MEDIUMTEXT, but that will be insignificant compared to the size of your data. VARCHAR and TEXT columns are handled the same way in InnoDB, so there is no reason to switch to VARCHAR either.


0

The only sure answer I can give to you is that you should be using a TEXT or BLOB datatype and not a varchar. Varchar leaves you with a chance that there wont be enough room for your data and your data can contain any type of information you require. Also (not really a problem) I would think you might be able to remove the recursive relationship in your ...


3

Triggers run, by default, under the security context of the principal who caused the trigger to fire. In order to change this behavior, you'll need to create the trigger using the WITH EXECUTE AS OWNER clause. Below is an example which shows how that works. WITH EXECUTE AS OWNER allows the trigger to run in the security context of the database owner, ...


1

This is an impressive ERD. Are you sure you want to have every table inherit from CreatedAtAbstractBase? The tables CarTypePanelPrice and CarModelPanelPrice are almost the same, differing only by car_model identifier. I would have the car_model field be optional (NULLable) and merge both tables. You'll know if one record is one type or the other if that ...


6

This simple question has caused an unusual amount of debate, and I feel compelled to quote an authoritative source. The database stores all data in tables that are related to one another. Relationships are established between tables such that data is shared and duplication is minimized. A table space is a storage structure containing tables, ...


-1

A database is a collection of schemas, a schema is a collection of tables/views/UDF/...


-1

schema = namespace within database, identical to user account database = single database


2

You cannot revoke the public pseudo-role from users. Every user always has public. You can revoke privileges from the public role. The first question would be whether these privileges were granted by default by Oracle, in which case revoking them might prove difficult. It might, for example, break upgrades and patches and/or be re-granted by future ...


3

No, that is not possible. You can wrap those names in square brackets, but that is not recommended, since it will likely cause a lot of confusion. For instance: CREATE SCHEMA [hr.report]; SELECT statements against objects in the schema would then look like: SELECT * FROM [hr.report].SomeTable;


2

You have the FOREIGN KEY relationships defined in the wrong direction. They should be the other way around, from medias to ads. The added UNIQUE constraint on medias (ad_id, media_type_id) takes care of the restriction that an ad can have only one media, for every media_type. This way, you can easily add more media types, just by inserting a new row in ...


1

Take a look at what Oracle says about this type of error. ORA-00942 table or view does not exist Cause: The table or view specified does not exist, a synonym that is not allowed here was used, or a view was referenced where a table is required. If you are trying to access tables or views of another schema then you might not have required privileges ...



Top 50 recent answers are included