New answers tagged

0

You have tradeoffs to consider when deciding on the design. Which do you want to optimize for: Insert new item Revise item Fetch "current" item Fetch some old revision Fetch all revisions If one of those actions dominates, then design for it, and kludge for the rest. Also, do revisions need extra columns, such as revisor, revision_date, ...


0

Do you define "different content" as row filtering via security settings? That is pretty standard - and pretty unusual (as in: standard for high security, not all databases support this thinking)... SQL Server for example is just adding this with version 2016 due this year. In most cases... people do not bother as the filtering of what data is visible is ...


1

The double quote " is actually specifying a field or an identifier. Use single quotes to specify your string filters: SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME='servers' ; Problem #2 could be you are USEing the wrong database. For example, if your table servers is in the schema mysql and you are currently using ...


0

First of all, why is your time slot of fixed length? Even with current design, you can have a slot with start_time = 9:00 and end_time = 9:20, and it can be one id. Furthermore, you can make a bridge table to connect type of exams (i.e. type 1 = first exam, type 2 = control exam etc) to length of slots, like this: exam_type slot_length_in_minutes 1 ...


0

This import file is an export done with a tool such as exp73, exp or expdp. The manner of importing data you are referring to when you have data in an excel sheet with coma separated value, SQL developer will create a large insert statement with the data for you and run it, which will populate a table. What you want to do is to use oracle import tools such ...


1

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

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 ...



Top 50 recent answers are included