/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Firebird og String
Fra : Ukendt


Dato : 03-02-07 12:28

Hej.

Hvad er Firebirds svar på en fielstype "string" (String = betegnelsen i
andre programmer)




 
 
Jens Gyldenkærne Cla~ (04-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 04-02-07 00:31

M&J skrev:

> Hvad er Firebirds svar på en fielstype "string" (String =
> betegnelsen i andre programmer)

Hvilke andre programmer?

I databasesammenhæng arbejder man normalt med char(x), varchar(x)
og text - og evt. med nchar(x), nvarchar(x) og ntext.

char/nchar er en streng med fast længde
varchar/nvarchar er en streng med variabel længde
text/ntext er en tekst med (næsten) ubegrænset længde

N-udgaverne gemmer indholdet i unicode - det fordobler den plads
der skal bruges til lagring, men sikrer til gengæld mod fejl på
grund af forskellige tegnsæt.

Ovenstående typer kan bruges i MSSQL og MySQL (sidstnævnte mangler
dog ntext så vidt jeg kan se) - og formentlig en del andre
databaser.

Jeg kender ingen databaser der anvender typen "string".
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

Ukendt (04-02-2007)
Kommentar
Fra : Ukendt


Dato : 04-02-07 01:26

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns98CD536CC4FCjcdmfdk@gyrosmod.cybercity.dk...
> M&J skrev:
>
>> Hvad er Firebirds svar på en fielstype "string" (String =
>> betegnelsen i andre programmer)
>
> Hvilke andre programmer?

Det var også programmeringssprog, som jeg har stødt på string og manglede en
parallel til DB-programmer.

> I databasesammenhæng arbejder man normalt med char(x), varchar(x)
> og text - og evt. med nchar(x), nvarchar(x) og ntext.
>
> char/nchar er en streng med fast længde

Vil det sige, at hvis man vælger char(10) så HAR den altid længden 10

> varchar/nvarchar er en streng med variabel længde

og hvis man vælger varchat(10) så har den HØJST længden 10

> text/ntext er en tekst med (næsten) ubegrænset længde
>
> N-udgaverne gemmer indholdet i unicode - det fordobler den plads
> der skal bruges til lagring, men sikrer til gengæld mod fejl på
> grund af forskellige tegnsæt.
>
> Ovenstående typer kan bruges i MSSQL og MySQL (sidstnævnte mangler
> dog ntext så vidt jeg kan se) - og formentlig en del andre
> databaser.
>
> Jeg kender ingen databaser der anvender typen "string".



Jens Gyldenkærne Cla~ (04-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 04-02-07 20:22

M&J skrev:

> Vil det sige, at hvis man vælger char(10) så HAR den altid
> længden 10

Ja. Hvis du indsætter en værdi der er kortere end 10, vil databasen
fylde op med mellemrumstegn (fx bliver "abc" indsat i en char(5)
til "abc ").

> og hvis man vælger varchat(10) så har den HØJST længden 10

Præcis. I praksis er varchar - i hvert fald i mine øjne - langt
mere anvendelig end char. Hvis man har tekstfelter som *altid* har
samme længde, sparer man lidt lagerplads ved at bruge char i stedet
for varchar, men til de fleste normale tekstfelter, er varchar mere
passende end char.

(og så er nvarchar ofte mere attraktiv end varchar til tekster der
kan indeholde danske tegn).


--
Jens Gyldenkærne Clausen
»Diplomatiet består netop i, at de gamle kommatister kan få lov til
at tro, at de har vundet. Men i virkeligheden har de tabt.«
Ole Togeby i Information

Ukendt (04-02-2007)
Kommentar
Fra : Ukendt


Dato : 04-02-07 21:57

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns98CDCF1F29F2Ejcdmfdk@gyrosmod.dtext.news.tele.dk...
> M&J skrev:

Hej igen.

Hvad med en værdi til at gemme sandt / falsk (true/false)



Jens Gyldenkærne Cla~ (04-02-2007)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 04-02-07 22:04

M&J skrev:

> Hvad med en værdi til at gemme sandt / falsk (true/false)

Nogle databaser har vist en boolean-felttype. I MSSQL bruger man
bit (mulige værdier 0 og 1 og evt. NULL).

--
Jens Gyldenkærne Clausen
»Diplomatiet består netop i, at de gamle kommatister kan få lov til
at tro, at de har vundet. Men i virkeligheden har de tabt.«
Ole Togeby i Information

Martin (05-02-2007)
Kommentar
Fra : Martin


Dato : 05-02-07 08:17

Jens Gyldenkærne Clausen wrote:
> M&J skrev:
>
>> Hvad med en værdi til at gemme sandt / falsk (true/false)
>
> Nogle databaser har vist en boolean-felttype. I MSSQL bruger man
> bit (mulige værdier 0 og 1 og evt. NULL).

Og i MySQL kunne man bruge ENUM (0,1)

Peter Brodersen (05-02-2007)
Kommentar
Fra : Peter Brodersen


Dato : 05-02-07 11:31

On Mon, 05 Feb 2007 08:17:15 +0100, Martin <maaNO@SPAMscandesigns.dk>
wrote:

>Og i MySQL kunne man bruge ENUM (0,1)

MySQL har også datatypen BIT fra og med MySQL 5.0


ENUM er lidt upassende her:

For det første tillader den også tomme værdier(ikke at forveksle med
null). Så et felt af typen ENUM('0','1') har fire mulige værdier:
'0', '1', '' og NULL

For det andet opererer den med strings (ENUM(0,1) giver fejl, mens
ENUM('0','1') ikke gør). I praksis kan det give en del forvirring og
uheldig konvertering mellem taltyper og stringtyper. Med ENUM('0','1')
får vi følgende resultat:

Indsætter man 0 (og ikke '0'), bliver der indsat ''
Indsætter man 1 (og ikke '1'), bliver der indsat '0'

Det kommer også til udtryk med fx INSERT INTO .. SELECT FROM fra en
tabel, der netop benytter sig af taltyper.


BIT kræver dog også at man indsætter en værdi med den rigtige
datatype, men her giver det noget mere mening. Men for en god ordens
skyld:

Indsætter man '0' (og ikke 0), bliver der indsat 1 / 0x1 / TRUE.

Det gælder dog for alle værdier over 0x1 at der bliver indsat får en
warning ('0' svarer til 0x30).

--
- Peter Brodersen
Kendt fra Internet

Martin (05-02-2007)
Kommentar
Fra : Martin


Dato : 05-02-07 11:52

Peter Brodersen wrote:
> ENUM er lidt upassende her:
>
> For det første tillader den også tomme værdier(ikke at forveksle med
> null). Så et felt af typen ENUM('0','1') har fire mulige værdier:
> '0', '1', '' og NULL

`test` ENUM( '0', '1' ) NOT NULL
Nu kan man ikke bruge NULL værdi

> Indsætter man 0 (og ikke '0'), bliver der indsat ''

Det går an på hvad man har sat default værdien til.

> Indsætter man 1 (og ikke '1'), bliver der indsat '0'

Korrekt - men nok det tætteste man kommer et true/false felt.

Indsætter man et felt med typen BOOL så bliver det en tinyint(1)
med NOT NULL.
Men så er der hele 10 muligheder (1,2,3,4,5,6,7,8,9,0)

Så der findes nok ikke en "korrekt" metode at lave et true/false felt i
MySQL 5

Peter Brodersen (05-02-2007)
Kommentar
Fra : Peter Brodersen


Dato : 05-02-07 12:27

On Mon, 05 Feb 2007 11:51:38 +0100, Martin <maaNO@SPAMscandesigns.dk>
wrote:

>> ENUM er lidt upassende her:
>>
>> For det første tillader den også tomme værdier(ikke at forveksle med
>> null). Så et felt af typen ENUM('0','1') har fire mulige værdier:
>> '0', '1', '' og NULL
>
>`test` ENUM( '0', '1' ) NOT NULL
>Nu kan man ikke bruge NULL værdi

Yep, men man kan stadigvæk indsætte værdien ''. Det er i mine øjne en
uhensigtsmæssighed ved ENUM-felter, at man ikke kan undgå '' som en
mulighed.

>> Indsætter man 0 (og ikke '0'), bliver der indsat ''
>Det går an på hvad man har sat default værdien til.

Nej - det er stadigvæk '', som bliver indsat:

mysql> CREATE TABLE enumtest (foo ENUM('0','1') DEFAULT '0' );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO enumtest (foo) VALUES (0);
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS;
+---------+------+------------------------------------------+
| Level | Code | Message |
+---------+------+------------------------------------------+
| Warning | 1265 | Data truncated for column 'foo' at row 1 |
+---------+------+------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM enumtest;
+------+
| foo |
+------+
| |
+------+
1 row in set (0.00 sec)

... og for at bevise at vores default-værdi virker:

mysql> TRUNCATE TABLE enumtest;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO enumtest () VALUES ();
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM enumtest;
+------+
| foo |
+------+
| 0 |
+------+
1 row in set (0.00 sec)

>Korrekt - men nok det tætteste man kommer et true/false felt.

I forhold til dataintegritet, så vil jeg stadigvæk mene at BIT (NOT
NULL) er mere passende. Her vil data aldrig kunne være andet end 0
eller 1.

>Indsætter man et felt med typen BOOL så bliver det en tinyint(1)
>med NOT NULL.

NOT NULL er dog ikke implicit i BOOL; man skal selv angive det.

mysql> CREATE TABLE booltest (foo BOOL);
Query OK, 0 rows affected (0.04 sec)

mysql> INSERT INTO booltest (foo) VALUES (NULL);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM booltest;
+------+
| foo |
+------+
| NULL |
+------+
1 row in set (0.03 sec)

>Men så er der hele 10 muligheder (1,2,3,4,5,6,7,8,9,0)

Nej, der er alle muligheder i TINYINT. 1-tallet i TINYINT(1) er ikke
en begrænsning i feltets mulige værdi, men omhandler blot padding (fx
foranstillede nuller). Fra manualen:

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
==
Another extension is supported by MySQL for optionally specifying the
display width of integer data types in parentheses following the base
keyword for the type (for example, INT(4)). This optional display
width is used to display integer values having a width less than the
width specified for the column by left-padding them with spaces.

The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column. For
example, a column specified as SMALLINT(3) has the usual SMALLINT
range of -32768 to 32767, and values outside the range allowed by
three characters are displayed using more than three characters.
==

Og for at bevise det:

mysql> TRUNCATE TABLE booltest;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO booltest (foo) VALUES
(0),(10),(50),(200),(500),(-10),(-100),(-1000);
Query OK, 8 rows affected, 3 warnings (0.00 sec)
Records: 8 Duplicates: 0 Warnings: 3

mysql> SHOW WARNINGS;
+---------+------+-------------------------------------------------------+
| Level | Code | Message |
+---------+------+-------------------------------------------------------+
| Warning | 1264 | Out of range value adjusted for column 'foo' at row 4 |
| Warning | 1264 | Out of range value adjusted for column 'foo' at row 5 |
| Warning | 1264 | Out of range value adjusted for column 'foo' at row 8 |
+---------+------+-------------------------------------------------------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM booltest;
+------+
| foo |
+------+
| 0 |
| 10 |
| 50 |
| 127 |
| 127 |
| -10 |
| -100 |
| -128 |
+------+
8 rows in set (0.02 sec)

>Så der findes nok ikke en "korrekt" metode at lave et true/false felt i
>MySQL 5

Dataintegritetsmæssigt må BIT være det nærmeste.

MySQL-folkene varsler dog at BOOL senere kommer til at blive
implementeret korrekt som sin egen type i overensstemmelse med
SQL-standarden.

--
- Peter Brodersen
Kendt fra Internet

Peter Brodersen (05-02-2007)
Kommentar
Fra : Peter Brodersen


Dato : 05-02-07 11:39

On Sun, 04 Feb 2007 20:21:39 +0100, "Jens Gyldenkærne Clausen"
<jens@gyros.invalid> wrote:

>Præcis. I praksis er varchar - i hvert fald i mine øjne - langt
>mere anvendelig end char. Hvis man har tekstfelter som *altid* har
>samme længde, sparer man lidt lagerplads ved at bruge char i stedet
>for varchar, men til de fleste normale tekstfelter, er varchar mere
>passende end char.

Nogle database-engines - fx MyISAM - vil kunne lave hurtigere opslag,
hvis alle felter i en tabel har en fast størrelse (fixed row format i
MySQL-terminologi).

Årsagen er ganske enkel. Hvis hver række garanteret fylder fx 45
bytes, så er det let for enginen at finde en vilkårlig række, idet den
i grove træk blot skal scanne 45*(n-1) bytes ind i datafilen for at
finde række n.

Fylder hver række noget forskelligt, skal enginen tillige slå op i en
fortegnelse (som også skal vedligeholdes) for at finde ud af, hvor
række n begnder i datafilen.

Vil man optimere sin tabel i forhold til hastighed, kan det nogle
gange betale sig at ofre lidt lagerplads for at give hurtigere opslag.
Har man fx en tabel med faste felter og så et tekstfelt, og ved at
tekstfeltet ikke kan fylde mere end 16 bytes, kan det måske være en
fordel at lave det om til et CHAR(16)-felt. Det betyder så at man
bruger lidt mere plads, men det er typisk et par bytes givet godt ud
når man har et par millioner rækker.

--
- Peter Brodersen
Kendt fra Internet

Søg
Reklame
Statistik
Spørgsmål : 177449
Tips : 31962
Nyheder : 719565
Indlæg : 6408120
Brugere : 218879

Månedens bedste
Årets bedste
Sidste års bedste