Boole değerlerini depolamak için kullanılacak MySQL veri türü


1207

MySQL 'boolean' veri türüne sahip olmadığından, MySQL'de doğru / yanlış bilgileri depolamak için hangi veri türünü 'kötüye kullanıyorsunuz'?

Özellikle bir PHP betiğinden / PHP betiğine yazma ve okuma bağlamında.

Zamanla çeşitli yaklaşımlar kullandım ve gördüm:

  • 0/1 değerlerini içeren tinyint, varchar alanları,
  • '0' / '1' veya 'true' / 'false' dizelerini içeren varchar alanları
  • ve son olarak 'true' / 'false' iki seçeneğini içeren alanları numaralandırır.

Yukarıdakilerin hiçbiri optimal görünmüyor. Ben PHP 0int1 otomatik tip dönüşüm bana oldukça basitçe boole değerleri verir, çünkü tinyint 0/1 varyant tercih eğilimindedir.

Peki hangi veri türünü kullanıyorsunuz? Göz ardı ettiğim boole değerleri için tasarlanmış bir tür var mı? Bir tür veya başka bir tür kullanarak herhangi bir avantaj / dezavantaj görüyor musunuz?


217
Bu sorunun eski yanıtlarını okuyan herkes, MySQL'in sürüm 5'e biraz veri türü eklediğini anlamalıdır. Bu bilgileri olabildiğince kullanın. dev.mysql.com/doc/refman/5.0/en/bit-type.html
smp7d


7
MYSQL Boolean tipinin mevcut sürümü için şu adresten ulaşabilirsiniz- dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html bunu kontrol edin. yanlış olarak kabul edilen bu değere göre
DevT

7
bit(1)Excel'de içe aktarmak için bir bit **. İşlere geçiş tinyint(1).
Cees Timmerman

8
Şimdi 5 yıl sonra boolean var
V-SHY

Yanıtlar:


1232

MySQL 5.0.3 ve üstü için kullanabilirsiniz BIT. Kılavuz şöyle diyor:

MySQL 5.0.3 itibariyle, BIT veri türü bit alanı değerlerini saklamak için kullanılır. Bir BIT (M) türü, M-bit değerlerinin saklanmasını sağlar. M 1 ila 64 arasında olabilir.

Aksi takdirde, MySQL kılavuzuna göre, şu anda tinyint diğer adları olan bool ve boolean'ı kullanabilirsiniz :

Bool, Boolean: Bu türler TINYINT (1) kelimesinin eş anlamlılarıdır . Sıfır değeri yanlış kabul edilir. Sıfır olmayan değerler doğru kabul edilir.

MySQL ayrıca şunları belirtir:

Gelecekteki bir MySQL sürümünde, standart SQL'e uygun olarak tam boolean işlemeyi gerçekleştirmeyi planlıyoruz.

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


11
Evet, ya bunu ya da bir CHAR (1) için gidip bağlama göre 'Y' / 'N' ya da 'T' / 'F' vb. Küçük bir tamsayı türü kullanmanın avantajı, RDBMS-
es'de

36
En azından PHP'de char için gitmek, daha !$booleanfazla işlem yapmadan asla düzgün bir şekilde değerlendirmeyeceği için daha fazla koda yol açacaktır .
Hafif Fuzz

10
@Pecerier Hiçbir şey kendin google yapamazsın, ama tamam, ısırırım. Her şeyden önce, lütfen data0type.h dosyasına bakın. İnnodb'un orada yerel olarak bir BIT türü tanımlamadığını lütfen unutmayın. BIT alanlarını tanımladığınız şekilde ele alırsa, kesinlikle orada varlığına dair bir ipucu buluruz. İkinci olarak, mysqlperformanceblog.com/2008/04/23/… adresini okuyun . Ve "marktetplace" deki inanılmaz MySQL istemcilerinin BIT alanları ile iyi oynadığını bize bildirmekten çekinmeyin. Şüphesiz bu makaleyi kaçıranlar için kullanışlı olacaklar.
Roland Bouman

9
Standart mysql komut satırından bir seçim yaptığımda istemci bit alanları tamamen boş görünüyor. Bu nedenle TINYINT'i (1) tercih ederim.
Kullanıcı

8
@MikePurcell Sormaktan nefret ediyorum ama neden auto_incrementboole değerini temsil eden bir sütunda istesin ki ?
Chris Hayes

248

BOOLve BOOLEANeş anlamlılarıdır TINYINT(1). Sıfır, falsebaşka bir şey true. Daha fazla bilgi burada .


7
Bu (1), değerin nasıl görüntülendiğini belirlemekten başka bir şey yapmaz, eğer depolama boyutu konusunda bilinçli iseniz, BITbunun yerine kullanmak istersiniz
JamesHalsall

35
@JamesHalsall: Aslında, BIT(1)ve TINYINT(1)depolama hem kullanımı bir byte olacak. MySQL 5.0.3'e kadar BIT, aslında bir eşanlamlıydı TINYINT. MySQL'in sonraki sürümleri BIT'in uygulanmasını değiştirdi. Ancak uygulama değişikliği ile bile, BITveri türüne hala "depolama boyutu" avantajı yoktur (en azından InnoDB ve MyISAM ile; diğer depolama motorları, örneğin NDB, birden çok BIT sütun bildirimi için bazı depolama optimizasyonuna sahip olabilir.) kütüphaneler döndürülen BITveri türü sütunlarını tanımaz veya uygun şekilde işlemez . A TINYINTdaha iyi çalışır.
spencer7593

5
MySQL 5.0 kılavuzu açıkça bir boolean değerinin 1 veya 0 trueolduğunu söylüyor. " Başka bir şey var " ifadesi doğru değil.
Walter

7
@Walter: Aslında biraz doğru, açıklama biraz eksik. Kısaca, bir boolean bağlamda, bir ifade NULL, FALSE veya TRUE olarak değerlendirilebilir. Bir MySQL deyiminde, bir boolean bağlamında değerlendirilen bir ifade ilk olarak tamsayı olarak değerlendirilir (ondalık ve kayan noktalı sayı değerleri yuvarlanır, MySQL, dizeleri tamsayıya dönüştürür. Bir NULL açıkça NULL (ne DOĞRU ne de YANLIŞ). 0 bir tam sayı değeri False olarak ele edilir ve herhangi bir başka tamsayı değeri (1, 2, -7, vs) doğru olarak değerlendirilir. Uyumluluk için, TINYINT boolean'ın mantığı / işlenişini taklit ediyoruz
spencer7593

4
@Walter: Test edilmesi kolaydır, örn SELECT 'foo' AS bar FROM dual WHERE -7. -7 ifadesi boole bağlamında değerlendirilir ve sorgu bir satır döndürür. 0 ile veya 0 tamsayı değeri olarak değerlendirilen herhangi bir ifadeyle test edebiliriz ve satır döndürülmez. WHERE deyimindeki ifade sıfır dışında null olmayan bir tam sayı değeri olarak değerlendirilirse ifade TRUE olur. (Ben ondalık ve hareketli değerler, örneğin tam sayıya "yuvarlak" olsun inanmak WHERE 1/3için değerlendirir WHERE 0. Biz aynı sonucu elde WHERE 'foo'dize, çünkü 'foo'aynı zamanda tamsayı değeri 0. olarak değerlendirilirse
spencer7593

71

Bu sıfır veri bayt kullandığından oldukça takdir zarif bir çözümdür:

some_flag CHAR(0) DEFAULT NULL

True some_flag = ''olarak ayarlamak için, false olarak ayarlamak için ayarlayın some_flag = NULL.

Sonra doğru olup olmadığını IS NOT NULLtest etmek için some_flag olup olmadığını kontrol edin ve false olup olmadığını test etmek için some_flag olup olmadığını kontrol edin IS NULL.

(Bu yöntem Jon Warren Lentz, Baron Schwartz ve Arjen Lentz tarafından yazılan "Yüksek Performanslı MySQL: Optimizasyon, Yedeklemeler, Çoğaltma ve Daha Fazlası" bölümünde açıklanmıştır.)


3
süslü numara! Bu, MySQL <5 ve belki de BIT'ten daha hafif bir ayak izi ile çalışırken faydalıdır, ancak konvansiyona ve biraz daha az hesaplama yüküne (mantık ve kesin değer) uymak için BIT'in daha iyi bir yol olduğunu söyleyebilirim.
zamnuts

59
'Hızlı' olabilir, ancak herhangi bir yeni geliştiricinin sütunun ne anlama geldiğine dair hiçbir fikri olmayacak şekilde verileri gizler.
Richthofen

5
Bu, BIT (1) ile aynı bayt miktarını kullanır
ITS Alaska

25
Bu güzel harita ORM almak iyi şanslar.
Craig Labenz

4
@Richthofen ile hemfikirim ve bu çözümü kullanarak savunacağım bir durum hayal etmekte zorlanıyorum. Bununla birlikte, kullanılacaksa, COMMENTsütunun tanımında NULLyanlış ve ''doğru olduğunu belirten bir olarak belirtilmesi, gelecekteki anlayışa yardımcı olmak için çok küçük bir yol olabilir.
eggyal

34

BOOLEAN türünü kullanırsanız, bu TINYINT (1) ile aynıdır. Standart SQL kullanmak istiyorsanız ve alanın aralık dışı bir değer içerebileceğini düşünmüyorsanız (temel olarak 0 olmayan bir şey 'doğru' olacaktır) bu en iyisidir.

ENUM ('False', 'True') SQL'inizdeki dizeleri kullanmanıza izin verir ve MySQL, alanı Enum'un belirtildiği sıraya göre 'False' = 0 ve 'True' = 1 olarak dahili bir tamsayı olarak saklar .

MySQL 5 ve üzeri sürümlerde, 1 bitlik sayısal bir türü belirtmek için bir BIT (1) alanı kullanabilirsiniz. Bunun aslında depolamada daha az yer kullandığına inanmıyorum, ancak yine de olası değerleri 1 veya 0 ile sınırlandırmanıza izin veriyor.

Yukarıdakilerin tümü yaklaşık olarak aynı miktarda depolama alanı kullanacağından, çalışmak için en kolay olanı seçmek en iyisidir.


8
ENUM ile ilgili görüşünüz doğru değil: CAST'ı (imzasız ASenumcol) deneyin ve False değerinin 1, True değerinin 2 olacağını fark edeceksiniz. ENUM ile ilgili bir başka sorun, eklemenin çok kolay olmasıdır '' (boş dize ). Bunu kullanmayı tavsiye etmem.
Roland Bouman

4
Deneyimlerime göre, PHP kodundan bir BIT (1) alanı kullanmak biraz zahmetli oldu. TINYINT (1) çok daha kolaydı ve daha okunabilir kod üretti.
M-Peror

1
@ M-Peror - "PHP kodundan bir BIT (1) alanı kullanmak biraz zahmetliydi" ... cinas amaçlı değildi. :) Ama evet, katılıyorum. TINYINT'in (1) daha kolay olduğunu da hatırlıyorum ... neden olduğunu hatırlayamıyorum. Bu konuda başka kimsenin düşüncesi var mı? BIT (1) yüzeyde daha hoş görünüyor, çünkü 0 veya 1 ile sınırlayabilirsiniz. BIT'nin bazen ikili veri olarak yorumlandığını düşünüyorum (programlama diline ve sürücüye / kütüphaneye bağlı olarak); oysa, TINYINT daha çok bir sayı gibi muamele gördü.
BMiner

2
@BMiner - haha, gerçekten istenmeyen, bunu fark etmedi :) Ama gerçekten, eğer doğru bir şekilde hatırlıyorsam, bit alanı ikili bir şey olarak yorumlanırken, tinyint'e sayı olarak davranmak daha kolaydı ve bu nedenle, (boole) ifadesinde kullanın.
M-Peror

34

Bu soru cevaplandı, ancak 0.02 $ 'ımı atacağımı düşündüm. Genellikle a CHAR(0), nerede kullanırım '' == true and NULL == false.

Gönderen MySQL docs :

CHAR(0)yalnızca iki değer alabilen bir sütuna ihtiyacınız olduğunda da oldukça güzeldir: olarak tanımlanan bir sütun CHAR(0) NULLyalnızca bir bit kaplar ve yalnızca değerleri NULLve ''(boş dize) alabilir.


16
mm, bu benim gibi olursan bela istiyor. Yani, dile bağlı olarak NULL ve '' (örneğin PHP) arasındaki farkı tespit etmek çok kolay olabilir.
Roland Bouman

3
Yerden tasarruf açısından (bir boole'yi temsil etmek için kullanılan bayt sayısı), bu yaklaşım açık bir kazanandır. Bu, TINYINT üzerinden bir bayt tasarrufu sağlar. Dezavantajı (bazı yorumların işaret ettiği gibi) bazı istemcilerin NULL ve boş bir dize arasında ayrım yapmakta zorluk çekebilmesidir. Bazı ilişkisel veritabanları bile (örneğin Oracle) sıfır uzunluklu bir dizeyle NULL arasında ayrım yapmaz.
spencer7593

3
Bu çok akıllı! Zekice kod yazardım, şimdi veba gibi kaçıyorum. Şimdi kodumun sadece doğru davranış değil, kristal berraklığında bir niyeti olmasını istiyorum. Benim tavsiyem? Bunu yalnızca kodu / veritabanını desteklemek zorunda olan birini karıştırmak istiyorsanız yapın. Örneğin, PHP'de hem ''ve hem nullde falsy değerleridir.
CJ Dennis

1
@CJDennis Veritabanı katmanınızı veri havuzu modelinin arkasında soyutladıysanız, bu çözümün belirsizliği konusunda endişelenmenize gerek yoktur.
prograhammer


17

Bit, yalnızca çok sayıda boole alanınız varsa çeşitli bayt seçeneklerine (tinyint, enum, char (1)) göre avantajlıdır. Bir bit alanı hala tam bir bayt kaplar. İki bit alan aynı bayta sığar. Üç, dört, beş, altı, yedi, sekiz. Bundan sonra bir sonraki baytı doldurmaya başlarlar. Nihayetinde tasarruflar çok küçük, odaklanmanız gereken binlerce başka optimizasyon var. Çok büyük miktarda veri ile uğraşmazsanız, bu birkaç bayt fazla toplamayacaktır. PHP ile bit kullanıyorsanız, girip çıkan değerleri yazmanız gerekir.


1
Tipik açıklama yorumu için +1. Programlama dilleriyle çalışırken buna eklemek için tutarlılık lehine tembel programlama teknikleri kullanmaktan kaçının. Eşit olmak yerine aynı işleçleri kullanın. PHP durumunda ($ var == "") 0, false, null, undefined ve "" için true olursa. tüm değerleri test etmek için tanımsız hatalardan da kaçınacağı için if (true === boş ($ var)) kullanmak en iyisidir. Ayrıca, if (is_int ($ var) && $ var === 0) ile birlikte çalıştığınız veri türünü doğrulamanız veya bunu görev için belirli bir veri türü (int) $ var olmaya zorlamak için yazmanız gerekir.
Ocak'ta fyrye

@ Bu MySQL için MSSQL için de aynı derecede geçerli mi? Henüz üretime girmemiş yeni bir uygulamayı MSSQL'den MySQL'e geçiriyorum. Ben PHP değil C # 8 yerine Java 8 dönüştürmek. Java güçlü yazılan bir dil olduğu göz önüne alındığında ben tür işleme hakkında endişe değil ... sadece 8 bayra kadar bir bayt hareket edecek tüm bit bayrakları TINYINT (1) verilen her bayrağa 1 bayt. MySQL için bu konuyla ilgili herhangi bir belge biliyor musunuz?
Zack Jannsen

1
@Thor Daha derin bir araştırma yaparak cevabın ne olması gerektiği açık. Değişim olur ve bu kullanımda gelişmeler gördük. Uygulama Katmanı / Veri Erişim Katmanı'nda kullanılacak dilinizi ve kitaplıklarınızın desteklediğini öğrenin. Şu anda Java kullanıyorum ve şu anda Hybernate ve JDBC kullanımı gibi kütüphaneler için BIT (1) önerilen seçimdir. İşte URL [Bkz. Tablo 5.2]: dev.mysql.com/doc/connector-j/en/…
Zack Jannsen

12

MySQL biraz veri tipi uygulayana kadar, işleminiz yüksek hacimli işlemler gibi alan ve / veya zaman için gerçekten basılıysa, bit_flagstüm boolean değişkenleriniz için çağrılan bir TINYINT alanı oluşturun ve SQL'inizde istediğiniz boolean bitini maskeleyin ve kaydırın sorgu.

Örneğin, en soldaki bitiniz bool alanınızı temsil ediyorsa ve en sağdaki 7 bit hiçbir şeyi temsil etmiyorsa, bit_flagsalanınız 128'e (ikili 10000000) eşit olacaktır. En sağdaki yedi biti (bitsel işlecini kullanarak) maskeleyin (gizleyin) ve &8. bit yedi boşluğu 00000001 ile bitecek şekilde sağa kaydırın. Şimdi tüm sayı (bu durumda 1 olan) sizin değerinizdir.

SELECT (t.bit_flags & 128) >> 7 AS myBool FROM myTable t;

if bit_flags = 128 ==> 1 (true)
if bit_flags = 0 ==> 0 (false)

Test ederken bunlar gibi ifadeler çalıştırabilirsiniz

SELECT (128 & 128) >> 7;

SELECT (0 & 128) >> 7;

vb.

8 bitiniz olduğundan, bir bayttan potansiyel olarak 8 boolean değişkeniniz vardır. Gelecekteki bazı programcılar her zaman sonraki yedi biti kullanacaktır, bu yüzden maskelemeniz gerekir . Sadece değişmeyin, gelecekte kendiniz ve başkaları için cehennem yaratacaksınız. Maskeleme ve kaydırma işleminizi MySQL yaptığınızdan emin olun - bu, web komut dosyası dilinin (PHP, ASP, vb.) Yapmasından çok daha hızlı olacaktır. Ayrıca, alanınız için MySQL yorum alanına bir yorum yaptığınızdan emin olun bit_flags.

Bu yöntemi uygularken bu siteleri yararlı bulacaksınız:


7
Bu, gelecekteki programcıların niyetini gizlemenin korkunç bir yolu gibi görünüyor. Tabii 7 bayt kurtarmak için çok fazla sorun gibi görünüyor (bu tek tabloda 8 boolsun tamamını kullandığınızı varsayarsak!)
evet

@yep hiç şaşkınlık yok! Tablodaki her alanı açıklayan belgeler ve MySQL yorumları yazın (cevaplardan bahsedildiği gibi)! Önerilen MySQL maskeleme stratejisi sağlam görünüyor ve sadece birkaç sütunla 16 farklı boole alanını depolamak , bunlardan 16'sına sahip olmaktan daha iyidir. Bit manipülasyonu kullanmak çok kafa karıştırıcıysa ve her bir boolean'ı almak için web komut dosyası dilini kullanmayı tercih ediyorsanız, bunu bir olarak depolayın ve koddaki maskeleme prosedürünü uygulayın (ayrıca 8 alanla sınırlamanız gerekmez) ...VARCHAR
CPHPython


10

Ben sıfırları, NULLS ve '' doğru bir PHP, MySql ve POST değerleri döngü yuvarlak almaya çalışırken bıkmış, bu yüzden sadece 'Evet' ve 'Hayır' kullanın.

Bu kusursuz çalışır ve açık ve kolay olmayan özel bir tedaviye ihtiyaç duymaz.


17
Gerçekten bu kadar alan harcamak ve performanstan ödün vermek istiyorsanız, Y ve N seçenekleriyle en az CHAR (1) yapmış olabilirsiniz.
ILikeTacos

3
Gerçek dünyadaki çoğu durumda 'hayır' ve sadece bilgi eksikliği arasında gerçek bir fark vardır. Örneğin, bir kullanıcı henüz 'hayır' demediyse varsayılan olarak bir onay kutusunun işaretli olmasını isteyebilirsiniz. Tam olarak ne kadar alan tasarrufu yaptığınızı düşünüyorsunuz ve yanlış ve NULL arasında her ayrım yapmanız gerektiğinde ne kadar işlem yapıyorsunuz - gerçekten de ayırt edebiliyorsanız? Saklanan görüntüler ve dijital video dünyasında, yer tasarrufu sağlayan bit veya iki tamamen önemsizdir, ancak netlik ve azaltılmış işleme gerçek.
Geoff Kendall

8
Bu cevap yanlış çünkü işe yarayacak ve insanlar ona kredi vermek kadar kötü değil. Çoğu proje için (örn: tablo boyutları <1mil satır) Sağlanan çözümler arasındaki performans farkları değişmez olacaktır. Sorgularım 7 vs 5 milisaniye içinde dönerse şikayetçi olmayacak ... Tabii ki tablolarınız 10mil veya daha fazla satır büyüyor, bu muhtemelen tercih edilen çözüm değildir.
Brad

1
ENUM veri türünü kullanmak için benden +1. Ben şahsen bu gösterimi tercih ederim: ENUM ('y', 'n'). Kompakt (sadece bir bayt uzunluğunda), sezgisel ve tüm boolean bayrakları için uygulama düzeyinde bir kural olarak iyi görünüyor. Doğrudan HTML form alanlarıyla kullanabilirsiniz. örneğin PHP ile: <select name = "production"> <seçenek değeri = "y" <? = $ production === 'y'? 'Seçili = "Seçili"': ''? >> Evet </option> <seçenek değeri = "n" <? = $ production === 'n'? 'seçildi = "seçildi"': ''? >> Hayır </option> </select>
Vlado

2
Lol bu gözüme çarptı ama @GeoffKendall haklı olduğunu söylemeliyim. Tonlarca durumda optimum performansa ihtiyaç yoktur ve işi sizin için hangi yöntem yaparsa yapsın doğru yöntemdir.
Madmenyo

6

Bu bağlantıya bakıldığında, Mysql'deki Boole veri türü , uygulama kullanımına göre, yalnızca 0 veya 1'in depolanmasını istiyorsanız, bit (1) daha iyi bir seçimdir.


6
BIT(1)Yalnızca bir b'0'veya b'1'değerin depolanmasına izin vereceği doğrudur . Veri tipiyle ilgili en büyük sorun BIT, çeşitli istemci kütüphanelerinin veri tipinde çeşitli sakat işlemlere sahip olmasıdır. Çeşitli SQL araçlarında (SQLyog, MySQL için TOAD, SQL Developer), veritabanı modellerini "tersine mühendislik" yapan araçlarda ve JDBC, PHP, Perl DBI gibi çeşitli istemcilerde ve iyi ölçülerde davranışı birkaç ORM çerçevesini test edin ( Hazırda Beklet, Mybatis, JPA). Kullanım kolaylığı açısından, araç / çerçeve uyumluluğu / yerel destek, TINYINT(1)açık kazanır.
spencer7593

Evet. Tamamlanır uygulaması için dikkate alınan çerçeveye bağlıdır. Örneğin, PHP'nin Phalcon çerçevesi Bit veri
tipini

Kayıt için, MyBatis BITve TINYINT. MyBatis'in JdbcType sınıfına bakın, mybatis.org/mybatis-3/apidocs/reference/org/apache/ibatis/type/…
Şanslı

1
@Vidz Size BIT'den bahsetmek için artı bir tane veriyorum (1) ama aynı zamanda bunu okuyan geliştiricilere de işaret ediyorum - Uygulama Katmanı / Veri Erişim Katmanı'nda olacak dilinizi ve kitaplıklarınızın desteğini öğrenin. Şu anda Java kullanıyorum ve şu anda Hybernate ve JDBC kullanımı gibi kütüphaneler için BIT (1) önerilen seçimdir. İşte URL [Bkz. Tablo 5.2]: dev.mysql.com/doc/connector-j/en/…
Zack Jannsen

6

MySQL (8.0.16) ve MariaDB (10.2.1) her ikisi de CHECK kısıtlamasını uyguladığından, şimdi

bool_val TINYINT CHECK(bool_val IN(0,1))

Yalnızca mağazaya mümkün olacak 0, 1ya NULLdönüştürülebilir değerlerin yanı sıra, 0ya 1gibi hatasız '1', 0x00, b'1'veya TRUE/ FALSE.

NULL'lara izin vermek istemiyorsanız, NOT NULLseçeneği ekleyin

bool_val TINYINT NOT NULL CHECK(bool_val IN(0,1))

Veya kullanırsanız TINYINT, neredeyse hiçbir fark olmadığını unutmayın .TINYINT(1)TINYINT(123)

Şemanızın yukarı doğru uyumlu olmasını istiyorsanız, BOOLveyaBOOLEAN

bool_val BOOL CHECK(bool_val IN(TRUE,FALSE))

db <> keman demosu


numaralandırma hakkında ne (0, 1)
santiago arizti

3
@santiagoarizti ENUM(olmalı enum('0', '1')- not: bunlar dize) iyi bir fikir değil. Dahili olarak nasıl saklandığı ve dize olmayan değerlerin nasıl ele alındığı nedeniyle çok fazla sorun var . Örneğin. 0ve FALSE depolanamaz. 1ve TRUEolur '0'. Ve 2olur '1'.
Paul Spiegel

MySQL 8+ kullananlar için en iyi cevap
dolmen

2

Burada cevapları okuduktan sonra kullanmaya karar verdim bit(1)ve evet, uzay / zaman içinde bir şekilde daha iyi, ama bir süre sonra fikrimi değiştirdim ve bir daha asla kullanmayacağım. Hazırlanan ifadeler, kütüphaneler vb. (Php) kullanırken gelişimimi çok karmaşık hale getirdi.

O zamandan beri her zaman kullanıyorum tinyint(1), yeterince iyi görünüyor.


3
Gelişiminizi ne şekilde karmaşıklaştırdığını açıklamak ister misiniz?
Chazy Chaz

@ChazyChaz SQL Server gibi diğer bazı dbs aksine 1/0 yerine doğru / yanlış bekliyor. Bu bazen doğru olarak ayarladığınızı düşündüğünüz garip durumlara yol açabilir, ancak aslında gerçekleşmez.
maembe

0

Boole değerlerini saklamak için BOOL, BOOLEAN veri türünü kullanabilirsiniz.

Bu tipler TINYINT (1) kelimesinin eş anlamlılarıdır.

Ancak, BIT (1) veri türü, bir boole değeri (true [1] veya false [0]) depolamak için daha mantıklıdır, ancak veri çıkışı, sorgulama vb. Yaparken TINYINT (1) ile çalışmak daha kolaydır. ve MySQL ve diğer veritabanları arasında birlikte çalışabilirlik sağlamak için. Bu yanıtı veya konuyu da kontrol edebilirsiniz .

MySQL ayrıca BOOL, BOOLEAN veri türlerini TINYINT'e dönüştürür (1).

Ayrıca, belgeleri okuyun

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.