Can one specify the EXTENDED storage type for a column as part of CREATE TABLE? If yes, would it also work under Postgres 8.1?
I don't see a way to do this except through ALTER TABLE, which seems weird for something that really belongs with the rest of the table definition.
I don' think you can.
http://www.postgresql.org/docs/9.1/static/storage-toast.html
"Each TOAST-able data type specifies a default strategy for columns of that data type, but the strategy for a given table column can be altered with ALTER TABLE SET STORAGE."
Related
I want to create new table with empty columns and specify the datatype later. Is it possible? I try to do so on myscompiler.io and it works. I don't know if it's just possible in such site or is it actually possible to create that once I use other tools to write my SQL.
No. The SQL syntax requires that a table be well-defined, with column names and data types. This is true in every database that I can think of.
You could possibly do what you want in one of three ways:
Your database might support some sort of generic type which you could use to define the column. For instance, SQL Server has a sql_variant type.
You could define the table with a specific type such as a string and change the type later using alter table.
You could define the table with a single primary key column and add columns as you decide what they are.
I don't recommend any of these approaches. Instead, I would suggest that you need to re-think how your application is structured. Tables represent entities and entities have properties. Generally when using databases, these things are known before you start doing any work. There may be some cases where dynamic table creation is useful, but that is definitely not the common approach when using databases.
Is there a way in Microsoft SQL to reference a specific item of data based on table, column and record?
For example, table A (COL1 INT, COL2 INT) has 2 records (1,2) and (3,4). Can I somehow capture value 4 by reference, rather than as "4"?
The purpose is to allow me to create an audit method that can point to specific value in a (table, column, record) without having to duplicate that value in my audit table (which could be large, therefore bloating my database size).
I am thinking ... just like Object_Id identifies a particular SQL object, so would this reference (some kind of GUID, perhaps?) identify a specific piece of data.
Many thanks in advance.
The answer is No. In MS SQL (and, as far as I know in other popular databases) there are no such references to specific values.
Moreover, even table rows in MS SQL do not have embedded unique identifiers, unless you take care to create an IDENTITY column.
You can yourself make the implementation of such references. For example, create a table with columns
data_id,
table_name,
row_id,
column_name
and fill it up every time you need a reference. Then you can refer to piece of data by data_id.
But this is not a good solution.
in most cases, a single entry in this table will consume more space
than the referenced data value itself
to get the values you still have to use dynamic sql
this will only work for tables that have an IDENTITY column and it
has the same name for all tables
and so on
I have an existing table called temp_09.jwn. I would like to add a new column called cobrand_bank_id. Is there a way where I can skip the ALTER TABLE step below and just directly write the insert into statement?
ALTER TABLE temp_09.jwn
ADD cobrand_bank_id int;
insert into temp_09.JWN(qqyy, cobrand_bank_id, sum)
No, you have to add the column first. Schema-less databases (NoSQL) can support this, but an RDBMS needs to have its scheme altered.
It's kind of like saying, "I bought these new shoes and I need a bin to store them, if I just toss them in the corner will a bin appear?" No, you have to get the bin first.
There are several options to achieve schema flexibility in an (SQL-) RDBMS:
1. use a Entity–attribute–value model
2. store a JSON document
Depending on your use case, data volume etc. a nosql db could be the better choice. But sometimes you need only one or a few tables to be schema-flexible and your other data is relational.
Some SQL RDBMS support schema flexible tables, E.g. SAP HANA ("CREATE TABLE ... WITH SCHEMA FLEXIBILITY...").
I am looking at creating temporal tables https://msdn.microsoft.com/en-us/library/mt604462.aspx in our database but I cant on a couple of tables that have computed columns.
The error message returned is rather self explanatory
"Computed column is defined with a user-defined function which is not allowed with system-versioned table"
but I was hoping there was a way to exclude or ignore columns from being tracked?
I have tried dropping the computed column creating the history table then adding the computed column back into the table but this didn't work.
Any help is appreciated.
Thanks
Edit -
I wasn't able to find a way to ignore columns from being tracked but we were able to refactor out the columns that used UDFs thus enabling us to use temporal tables.
I was struggling with adding a computed column to an existing system-versioned table. In case anyone else with a similar problem lands here, I finally realized that the history table doesn't treat the column the same way. It ends up being similar to having an IDENTITY column on the base table, but that would result in a regular INT field on the history table.
If you are attempting to add a computed column to a system-versioned (temporal) table:
First turn off system versioning
Then add your computed column to the base table
Verify the "type" of the resulting computed column
Add the column with the appropriate static type to the history table
Turn system versioning back on (DO NOT FORGET TO SPECIFY THE HISTORY TABLE)
I find it rather odd that you can accidentally omit the history_table when turning system versioning back on. I'd expect either it would resume versioning to the same table OR throw some kind of error considering it might be a bit unexpected behavior.
#pasquale-ceglie - I don't have enough reputation to comment, but I wanted to expand on what you said. You should be able to use most computed columns with temporal tables, just more manually. Basically you can't copy the schema definition with the computed columns, you can however replicate the resulting columns and generate the appropriate history table before trying to turn everything on. The definitions are just a bit different between the two tables (was quite confusing to me at first). I subscribed here, ping me if the above isn't clear and are curious.
System-versioned table schema modification fail because adding computed column while system-versioning is ON is not supported, so for the same reason you can't transform a regular table into a temporal one if there are computed columns on it.
Hope will help,
In my project I use a sqlite database, unfortunately my friend have make an error. A field is with no correct type.
So for the moment when the data in the field 'localid' (declare as integer) is more than 2147483647, all entry in this field is set to the max 2147483647.
The alter table/alter column sql request do not works with sqlite because it supports a limited subset of ALTER TABLE : only rename and add a new column.
So how can I make a change without data loss? create a new database correctly, coppy all data into it and delete the old?
But maybe there is a better way ? Someone have an idea?
Proceed like this:
create temporary table that contains fields that form the primary
key and localid (I assume this is nor PK).
fill temporary table
drop old column
add new column
fill new column by selecting from temporary table (+ possible conversion to new type).
Don't forget possible foreign keys if column is used as such and remember possibility to temporally relax constraint if it makes conversion smooth (likely not needed in your case).