I would like to ask about why sensenet chooses the following numbers for the number of primitive properties per page:
nvarchar : 80
int : 40
datetime : 25
money : 15
Is it related to sql server max record size whcih is 8 K Bytes?
thanks.
Yes, and at the time when this structure was designed, sql server allowed a limited number of columns too. These numbers are based on the assumption that you'll need text fields mostly and fewer money columns.
But this does not really matter, because there is paging implemented here, so you can register any number of fields in a ctd. If you use more text fields than the number of columns, those values will simply be stored in a new row in the flatproperties table.
Related
I am facing the column length issue in my table and I want to change column type to big int from int and table rows around 1K million records but when ever I tried to change data type it is taking to much time and it is eating my machine all space, what is best way and fast way to change the column data type on this big table, currently table has no indexes.
Currently Column length
ID 4(Length) 10(prec)
Tried
I added new column and set their datatype to big int and made update query
Suggestion
Select insert into newtable is fact way but can we set column type with this query ?
Table Size :
Issue resolved and its takes around less than 2 hours and resolved by following steps.
Create empty table with new Column Data type
Made around 21 batch scripts
Create clustered index on big int column
Oracle has a max column limit of 1000 and even with all columns defined as VARCHAR(4000) I was able to create the table and load huge amounts of data in all fields.
I was able to create a table in SQL Server with 500 varchar(max) columns, however when I attempt to insert data, I got the following error:
Cannot create a row of size 13075 which is greater than the allowable
maximum row size of 8060.
When I made the table 200 columns I was able to insert huge amounts of data.
Is there a way to do this in SQL Server?
I ran some test and it seems we have an overhead of 26 bytes on each populated varchar(max) column.
I was able to populate 308 columns.
If you'll divide your columns between 2 tables you'll be fine (until the next limitation - which will come).
P.s.
I seriously doubt the justification for this table structure.
Any reason not saving the data as rows instead of columns?
I have an indexed (nonclustered) string column (let's just call it 'Identifier') on a table with the following row values:
`0000001`
`0000245`
`001`
`AB0001`
I want to be able to efficiently return all the rows that have an Identifier ending with a certain number entered by the user. For example, when the user enters 1 then the following rows should be returned:
0000001
001
AB0001
The problem is that using WHERE Identifier LIKE CONCAT(N'%', #UserInput) uses an index scan which doesn't scale well, since the table has tons of rows in it (many millions)
How should I efficiently query this data? My first thought is to add a new column that represents the REVERSE() of the Identifier column, and then use WHERE ReversedIdentifier LIKE CONCAT(REVERSE(#UserInput), N'%') to find the matches using a "starts with"
This doesn't seem like the cleanest solution, but it's all I can think of at the moment. Is there a better way?
If you have a column that holds the number component and that column is a number and used that column in an index ... that would be a lot faster.
I'm working on a call/bug tracking script and whats the best practice when generating unique tracking ids for each issue.
is it best to use the index in mysql
is there another format I could use
how do i handle the display format, i like to display a 6(345789) digit number.
if it goes over 6 digit, how do i start over again or how do I handle this?
or is it best to create a new field and generate the numbers?
suggestions???
thanks
If you use all six digit numbers, you must have less than 900,000 records or you will run out of unique values. There is no way around this except to use more digits or change the data type to varchar and allow alphanumeric values. If you don't think you'll ever have 900,000 records, I would use a mysql auto increment column, but set the sequence to start at the first six digit number (100000). You would create your table like this...
CREATE TABLE bugs
(
tracking_id INT UNSIGNED NOT NULL AUTO_INCREMENT = 100000,
...
)
So, the first tracking_id generated when you create a record would be 100000, then 100001 and so on. If you insert more than 899,999 records (exceeding 999,999) the number of digits will increase to 7 though.
i have created table in oracle. one column is as follow:
GUID NUMBER(16),
But value of this cloumn is shown 1,01000037073356E15
how can i correct it?
The preferred storage data type for GUID values on Oracle is RAW(16).
A GUID is not a number in the sense that your height is a number -- you are not going to add them together, or take their average, for example.
http://docs.oracle.com/cd/B28359_01/server.111/b28286/functions175.htm
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:77564387253035