Boole"scher Datentyp

Hallo allerseits,

kennt MySQL keinen boole'schen Datentyp? Ich habe im Handbuch (4.0)
nichts gefunden.

Gruß. Claus

Re: Boole"scher Datentyp

Claus Reibenstein wrote:
> kennt MySQL keinen boole'schen Datentyp? Ich habe im Handbuch (4.0)
> nichts gefunden.

AFAIR wurde die Unterstützung in MySQL 5 eingeführt. Im 5er-Handbuch ist
BOOL beschrieben:

http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview .html

Allerdings ist BOOL nur ein Alias für TINYINT(1) und TRUE bzw. FALSE
Aliase für 1 bzw. 0. Das heißt ohne den Syntaktischen Zucker kannst du
in kleineren Versionen TINYINT(1), 0 und 1 benutzen.

Grüße
Kai

--
This signature is left as an exercise for the reader.

Re: Boole"scher Datentyp

Kai Ruhnau schrieb:

> AFAIR wurde die Unterstützung in MySQL 5 eingeführt. Im 5er-Handbuch ist
> BOOL beschrieben:
>
> http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview .html

Im 3.23er ebenfalls:



| BOOL, BOOLEAN
|
| These types are synonyms for TINYINT(1). The synonym BOOLEAN was added
| in MySQL 4.1.0. A value of zero is considered false. Non-zero values
| are considered true:

gruss, heli

Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Kai Ruhnau schrieb:
>
> Allerdings ist BOOL nur ein Alias für TINYINT(1) und TRUE bzw. FALSE
> Aliase für 1 bzw. 0. Das heißt ohne den Syntaktischen Zucker kannst du
> in kleineren Versionen TINYINT(1), 0 und 1 benutzen.

Wo ist eigentlich der Vorteil von TINYINT(1) im Gegensatz zu einem ENUM
('0', '1')?

regards,
Jens

Re: Wieso Tinyint?

Jens Himmelrath wrote:
> Kai Ruhnau schrieb:
>>
>> Allerdings ist BOOL nur ein Alias für TINYINT(1) und TRUE bzw. FALSE
>> Aliase für 1 bzw. 0. Das heißt ohne den Syntaktischen Zucker kannst du
>> in kleineren Versionen TINYINT(1), 0 und 1 benutzen.
>
> Wo ist eigentlich der Vorteil von TINYINT(1) im Gegensatz zu einem ENUM
> ('0', '1')?

Ich rate mal, das es da schlicht keinen Vorteil gibt sondern Mysql
nur keinen Boolean kennt und dafür einfach einen Tinyint hernimmt.
Es wird sowieso ein Byte verbraucht, ob davon jetzt nur ein einzelnes
Bit genutzt wird oder alle acht, ist fast egal.

Dafür kannst du dann auch Quantenwerte berechnen, weil überlagerte
Zustände (also != 0 und 1) möglich sind. Hat alles seine ... Vorteile.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath schrieb:
> Kai Ruhnau schrieb:
>>
>> Allerdings ist BOOL nur ein Alias für TINYINT(1) und TRUE bzw. FALSE
>> Aliase für 1 bzw. 0. Das heißt ohne den Syntaktischen Zucker kannst du
>> in kleineren Versionen TINYINT(1), 0 und 1 benutzen.
>
> Wo ist eigentlich der Vorteil von TINYINT(1) im Gegensatz zu einem ENUM
> ('0', '1')?
>
> regards,
> Jens

Es ist (k)eine reine Speicherfrage ;) Die Sache ist die, dass ENUM bei
entsprechender Anzahl Werte (>32767) eben 2 Bytes braucht, in diesem
Fall ist das zu vernachlässigen... TinyInt ist immer 1 Byte groß...

btw: Die 1 in klammern kann man sich getrost sparen... TINYINT ist immer
1 Byte, sprich maximalwerte -128 verwenden, wenn nur positive Werte benötigt werden, in diesem Fall
gilt:0
ENUM ist imho jedoch unter Umständen etwas langsamer, da
Zeichenkettenwerte aufwendiger zu vergleichen sind, als rein numerische
Werte...

So long!
alex

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Alex Hepp schrieb:
>
> ENUM ist imho jedoch unter Umständen etwas langsamer, da
> Zeichenkettenwerte aufwendiger zu vergleichen sind, als rein numerische
> Werte...

Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
some_integer='123'" schreibe es dadurch in der Masse signifikant
langsamer werden kann?

regards,
Jens, der sich gerade fragt, wieso er da bisher noch nie drüber
nachgedacht hat.

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath wrote:
> Alex Hepp schrieb:
>>
>> ENUM ist imho jedoch unter Umständen etwas langsamer, da
>> Zeichenkettenwerte aufwendiger zu vergleichen sind, als rein
>> numerische Werte...
>
> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
> some_integer='123'" schreibe es dadurch in der Masse signifikant
> langsamer werden kann?

Nicht signifikant. Nach dem Parsen wird das einmal umgewandelt und dann
läuft der teure Kram (Optimierung, Daten suchen, Daten ausliefern) mit
dem Integer-Wert ab.

Aber es ist schlicht falsch. some_integer ist eben nichts, was sich
gegen einen String vergleichen lässt. Dass MySQL das unterstützt ist
mehr oder weniger ein Tribut an die viele Script-Programmierer da
draußen, die nie den echten Unterschied zwischen Strings und Integers
gelernt haben ("Wieso? Macht doch alles der Computer!").
Andere Datenbanken schmeißen dir diese nicht passenden Typen um die Ohren.

> regards,
> Jens, der sich gerade fragt, wieso er da bisher noch nie drüber
> nachgedacht hat.

Weil man das in der heutigen Zeit "nicht mehr muss", schließlich
verwischt quasi jede Technologie im Zusammenhang mit dem Web diese Grenze.

Grüße
Kai

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath schrieb:

> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
> some_integer='123'" schreibe es dadurch in der Masse signifikant
> langsamer werden kann?

Also es gibt ja 2 Möglichkeiten:

1. MySQL nimmt einfach an, dass Du definitiv einen Zahlenwert angegeben
hast, und spart sich parsen etc., sollte dann kein reiner Zahlenwert
vorhanden sein, schlägt eben einfach der Vergleich fehl!

2. Aus der Zeichenkette wird erstmal versucht, einen Zahlenwert
herauszuparsen.

Da ich das nicht genau wusste, hab ich mal was ausprobiert:

CREATE TABLE `test` (
`test` int(11) NOT NULL default 0
)

INSERT INTO `test` VALUES (2),(3);

SELECT *
FROM `test`
WHERE test = '2b';

Und siehe da, ich bekomme tatsächlich die eine Zeile zurück, das sagt
mir, dass wohl intern erstmal geparst wird, was die Sache dann natürlich
verlangsamen dürfte, aber ob das wirklich ins Gewicht fällt, bedarf wohl
einer Untersuchung ;)

gruß alex

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Alex Hepp schrieb:
> Jens Himmelrath schrieb:
>
>> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
>> some_integer='123'" schreibe es dadurch in der Masse signifikant
>> langsamer werden kann?
>

Nachtrag: Ich hab noch vergessen, zu erwähnen, dass das nicht unbedingt
der Vergleich war, den ich meinte, es ging mehr darum, dass es
aufwendiger ist, zb.

WHERE MY_VARCHAR = '1' zu vergleichen, als
WHERE MY_TINYINT = 1.

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath wrote:
> Alex Hepp schrieb:
>>
>> ENUM ist imho jedoch unter Umständen etwas langsamer, da
>> Zeichenkettenwerte aufwendiger zu vergleichen sind, als rein numerische
>> Werte...
>
> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
> some_integer='123'" schreibe es dadurch in der Masse signifikant
> langsamer werden kann?

Ja. Ich kann mich erinnern, daß ich mal eine MySQL-Version unter den
Fingern hatte, die in diesem Fall einen Index auf some_integer nicht
verwendet hat. Ist aber AFAIK lange gefixt. Und es war IIRC anders
herum: eine CHAR(1) Spalte wurde mit 5 verglichen.


XL

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath schrieb:
> Alex Hepp schrieb:
>>
>> ENUM ist imho jedoch unter Umständen etwas langsamer, da
>> Zeichenkettenwerte aufwendiger zu vergleichen sind, als rein numerische
>> Werte...
>
> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
> some_integer='123'" schreibe es dadurch in der Masse signifikant
> langsamer werden kann?

Also im Microsoftschen Sql-Server zumindest wird eine Query mit falschem
Datentyp /richtig/ langsam. Der Unterschied war sowas wie 3Minuten zu
<1s (allerdings war das nvarchar<->varchar).

Keine Ahnung, ob das hilft, aber da wir es ja vermutlich über PostreSQL
bald auch wissen, wollte ich es mal anbringen.

Grüße,
--
Philipp Tölke
PGP: 0x96A1FE7A

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Jens Himmelrath wrote:
> Wo ist eigentlich der Vorteil von TINYINT(1) im Gegensatz zu einem ENUM
> ('0', '1')?

Du kannst auch ein CHAR(0) NULL verwenden, wenn Du magst.

root@localhost [kris]> create table n ( n char(0) null );
Query OK, 0 rows affected (0.03 sec)
root@localhost [kris]> insert into n values ( "" ), ( NULL );
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

root@localhost [kris]> select * from n;
+------+
| n |
+------+
| |
| NULL |
+------+
2 rows in set (0.00 sec)



Hier im Vergleich:

root@localhost [kris]> show create table n\G
*************************** 1. row ***************************
Table: n
Create Table: CREATE TABLE `n` (
`n` char(0) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> select count(*) from n;
+----------+
| count(*) |
+----------+
| 256 |
+----------+
1 row in set (0.00 sec)

root@localhost [kris]> select * from n limit 2;
+------+
| n |
+------+
| |
| NULL |
+------+
2 rows in set (0.00 sec)

root@localhost [kris]> show table status like "n"\G
*************************** 1. row ***************************
Name: n
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:10:05
Update_time: 2006-09-22 17:12:26
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


root@localhost [kris]> show create table nn\G
*************************** 1. row ***************************
Table: nn
Create Table: CREATE TABLE `nn` (
`n` enum('0','1') default NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> select count(*) from nn;
+----------+
| count(*) |
+----------+
| 256 |
+----------+
1 row in set (0.00 sec)

root@localhost [kris]> select * from nn limit 2;
+------+
| n |
+------+
| 0 |
| 1 |
+------+
2 rows in set (0.00 sec)

root@localhost [kris]> show table status like "nn"\G
*************************** 1. row ***************************
Name: nn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:09:15
Update_time: 2006-09-22 17:13:17
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

root@localhost [kris]> show create table nnn\G
*************************** 1. row ***************************
Table: nnn
Create Table: CREATE TABLE `nnn` (
`n` tinyint(3) unsigned default NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> select count(*) from nnn;
+----------+
| count(*) |
+----------+
| 256 |
+----------+
1 row in set (0.00 sec)

root@localhost [kris]> select * from nnn limit 2;
+------+
| n |
+------+
| 0 |
| 1 |
+------+
2 rows in set (0.00 sec)

root@localhost [kris]> show table status like "nnn"\G
*************************** 1. row ***************************
Name: nnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:10:52
Update_time: 2006-09-22 17:13:48
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


Es bleibt sich also alles gleich.

Kris

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Kristian Köhntopp wrote:
> Hier im Vergleich:
>

Methode 4:

root@localhost [kris]> show create table nnnn\G
*************************** 1. row ***************************
Table: nnnn
Create Table: CREATE TABLE `nnnn` (
`n` bit(1) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.07 sec)

root@localhost [kris]> select count(*) from nnnn;
+----------+
| count(*) |
+----------+
| 256 |
+----------+
1 row in set (0.00 sec)

root@localhost [kris]> select hex(n) from nnnn limit 2;
+--------+
| hex(n) |
+--------+
| 0 |
| 1 |
+--------+
2 rows in set (0.00 sec)

root@localhost [kris]> show table status like "nnnn"\G
*************************** 1. row ***************************
Name: nnnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:16:37
Update_time: 2006-09-22 17:19:49
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Kristian Köhntopp wrote:
> ...

Weiterhin:

root@localhost [kris]> alter table n add column m char(0) charset latin1
collate latin1_bin null;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> update n set m=n;
Query OK, 128 rows affected (0.01 sec)
Rows matched: 256 Changed: 128 Warnings: 0

root@localhost [kris]> show create table n\G
*************************** 1. row ***************************
Table: n
Create Table: CREATE TABLE `n` (
`n` char(0) character set latin1 collate latin1_bin default NULL,
`m` char(0) character set latin1 collate latin1_bin default NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> show table status like "n"\G
*************************** 1. row ***************************
Name: n
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:23:40
Update_time: 2006-09-22 17:23:47
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.01 sec)


root@localhost [kris]> alter table nn add column m enum("0", "1") not null;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> alter table nn change column n n enum("0", "1") not
null;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> update nn set m = n;
Query OK, 128 rows affected (0.00 sec)
Rows matched: 256 Changed: 128 Warnings: 0

root@localhost [kris]> show create table nn\G
*************************** 1. row ***************************
Table: nn
Create Table: CREATE TABLE `nn` (
`n` enum('0','1') NOT NULL,
`m` enum('0','1') NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> show table status like "nn"\G
*************************** 1. row ***************************
Name: nn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:25:18
Update_time: 2006-09-22 17:25:22
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


root@localhost [kris]> alter table nnn add column m tinyint unsigned not
null;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> update nnn set m=n;
Query OK, 128 rows affected (0.00 sec)
Rows matched: 256 Changed: 128 Warnings: 0

root@localhost [kris]> show create table nnn\G
*************************** 1. row ***************************
Table: nnn
Create Table: CREATE TABLE `nnn` (
`n` tinyint(3) unsigned NOT NULL,
`m` tinyint(3) unsigned NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> show table status like "nnn"\G
*************************** 1. row ***************************
Name: nnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:26:18
Update_time: 2006-09-22 17:26:22
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


root@localhost [kris]> alter table nnnn add column m bit(1) not null;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> update nnnn set m=n;
Query OK, 128 rows affected (0.00 sec)
Rows matched: 256 Changed: 128 Warnings: 0

root@localhost [kris]> show create table nnnn\G
*************************** 1. row ***************************
Table: nnnn
Create Table: CREATE TABLE `nnnn` (
`n` bit(1) NOT NULL,
`m` bit(1) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@localhost [kris]> show table status like "nnnn"\G
*************************** 1. row ***************************
Name: nnnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:26:58
Update_time: 2006-09-22 17:27:03
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


Unterschiede ergeben sich bei noch mehr Spalten:


root@localhost [kris]> show table status like "n"\G
*************************** 1. row ***************************
Name: n
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:29:03
Update_time: 2006-09-22 17:29:03
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

Jedoch:

root@localhost [kris]> alter table nn add column a0 enum('0','1') NOT NULL,
add column a1 enum('0','1') NOT NULL, add column a2 enum('0','1') NOT NULL,
add column a3 enum('0','1') NOT NULL, add column a4 enum('0','1') NOT NULL,
add column a5 enum('0','1') NOT NULL, add column a6 enum('0','1') NOT NULL,
add column a7 enum('0','1') NOT NULL;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0
root@localhost [kris]> show table status like "nn"\G
*************************** 1. row ***************************
Name: nn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 11
Data_length: 2816
Max_data_length: 3096224743817215
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:30:24
Update_time: 2006-09-22 17:30:24
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)

und

root@localhost [kris]> alter table nnn add column a0 tinyint(3) unsigned NOT
NULL, add column a1 tinyint(3) unsigned NOT NULL, add column a2 tinyint(3)
unsigned NOT NULL, add column a3 tinyint(3) unsigned NOT NULL, add column
a4 tinyint(3) unsigned NOT NULL, add column a5 tinyint(3) unsigned NOT
NULL, add column a6 tinyint(3) unsigned NOT NULL, add column a7 tinyint(3)
unsigned NOT NULL;
Query OK, 256 rows affected (0.06 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> show table status like "nnn"\G
*************************** 1. row ***************************
Name: nnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 11
Data_length: 2816
Max_data_length: 3096224743817215
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:31:52
Update_time: 2006-09-22 17:31:52
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.01 sec)

während

root@localhost [kris]> alter table nnnn add column a0 bit(1) NOT NULL, add
column a1 bit(1) NOT NULL, add column a2 bit(1) NOT NULL, add column a3
bit(1) NOT NULL, add column a4 bit(1) NOT NULL, add column a5 bit(1) NOT
NULL, add column a6 bit(1) NOT NULL, add column a7 bit(1) NOT NULL;
Query OK, 256 rows affected (0.01 sec)
Records: 256 Duplicates: 0 Warnings: 0

root@localhost [kris]> show table status like "nnnn"\G
*************************** 1. row ***************************
Name: nnnn
Engine: MyISAM
Version: 10
Row_format: Fixed
Rows: 256
Avg_row_length: 7
Data_length: 1792
Max_data_length: 1970324836974591
Index_length: 1024
Data_free: 0
Auto_increment: NULL
Create_time: 2006-09-22 17:33:03
Update_time: 2006-09-22 17:33:03
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.00 sec)


Dies alles mit

root@localhost [kris]> select version();
+----------------+
| version() |
+----------------+
| 5.0.18-max-log |
+----------------+
1 row in set (0.00 sec)

Kris

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Philipp Tölke wrote:

>> Das heißt also, dass wenn ich bei meiner Query aus Gewohnheit "WHERE
>> some_integer='123'" schreibe es dadurch in der Masse signifikant
>> langsamer werden kann?

Wenn eine DBMS beim Vergleich von zwei unterschiedlichen Datentypen
keinen Fehler zurückgibt, sondern einen automatiischen Typecast macht,
dann gelten Regeln für die Rangfolge von Datentypen, ähnlich wie "Punkt
vor Strich":
Numerische Datentypen sind "höherwertiger" als Strings.

Bei einem "numeric_col = '123'" muss der String in einen numerischen
Wert umgewandelt werden. Das braucht nur einmal gemacht werden und
entsprechend kann das schon der Optimizer.

Bei einem "char_col = 123" muss auch der String in einen numerischen
Wert umgewandelt werden, da der Wert 123 auf beliebig viele Arten als
String dargestellt werden kann: '123', '1.23e+02', '123.0', usw.
Das muss jetzt für jede Row gemacht werden und erfordert einen Full
Table Scan.

> Also im Microsoftschen Sql-Server zumindest wird eine Query mit falschem
> Datentyp /richtig/ langsam. Der Unterschied war sowas wie 3Minuten zu
> <1s (allerdings war das nvarchar<->varchar).

Das war dann wohl der zweite Fall :-)

Dieter

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Kristian =?UTF-8?B?S8O2aG50b3Bw?= wrote:

[snip]

Dir ist langweilig. Geh ins Bett!


XL ;-)

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Axel Schwenke wrote:
> Kristian =?UTF-8?B?S8O2aG50b3Bw?= wrote:
> Dir ist langweilig. Geh ins Bett!

Zusammenfassung für meine ungeduldigen Kollegen: Für ein einzelnes Bit macht
es keinen Unterschied, ob man CHAR(0) NULL, ENUM("0","1") NOT NULL,
TINYINT(1) NOT NULL oder BIT(1) NOT NULL verwendet. Auch für zwei Bits ist
es noch unerheblich, wenn sich sonst nix in der Tabelle befindet.

Definiert man jedoch 10 Bits, stellt man fest, daß ein BIT(1) NOT NULL oder
ein CHAR(0) NULL effizientere Datentypen sind als ein ENUM("0", "1") NOT
NULL oder ein TINYINT(1) NOT NULL.

Danke für Eure Aufmerksamkeit und eine angenehme Nacht,
Kris

Re: Wieso Tinyint? (Was: Re: Boole"scher Datentyp)

Kai Ruhnau schrieb:
>
>> regards,
>> Jens, der sich gerade fragt, wieso er da bisher noch nie drüber
>> nachgedacht hat.
>
> Weil man das in der heutigen Zeit "nicht mehr muss", schließlich
> verwischt quasi jede Technologie im Zusammenhang mit dem Web diese Grenze.

Und dabei bin ich einer von den Leuten die an PHP nicht mögen, dass es
eben nicht streng typisiert ist... :)

regards,
Jens