Microsoft SQL Server에서 비트 필드 대신 "y"/"n"을 사용하는 이유는 무엇입니까?

Question

저는 다른 폭도들이 개발 한 응용 프로그램을 작업하고 있으며 데이터베이스의 모든 부울 열에 비트 대신 숯 필드를 사용하여 혼란스러워합니다. true에는 "y", false에 "n"을 사용합니다 (대문자 여야 함). 유형 이름 자체는 ybln.

이것은 여러 가지 이유로 함께 일하는 것이 매우 성가신 일이며, 그 중 가장 적은 것은 미학적으로 무성하게 보이는 것처럼 보입니다.

하지만 어쩌면 그게 바보 일 수도 있습니다. 왜 누군가 이것을할까요? 데이터베이스 호환성 문제 또는 내가 알지 못하는 일부 설계 패턴입니까?

누구든지 나를 깨달을 수 있습니까?

Answer 1

I've seen this practice in older database schemas quite often. One advantage I've seen is that using CHAR(1) fields provides support for more than Y/N options, like "Yes", "No", "Maybe".

Other posters have mentioned that Oracle might have been used. The schema I referred to was in-fact deployed on Oracle and SQL Server. It limited the usage of data types to a common subset available on both platforms.

They did diverge in a few places between Oracle and SQL Server but for the most part they used a common schema between the databases to minimize the development work needed to support both DBs.

Answer 2

Welcome to brownfield. You've inherited an app designed by old-schoolers. It's not a design pattern (at least not a design pattern with something good going for it), it's a vestige of coders who cut their teeth on databases with limited data types. Short of refactoring the DB and lots of code, grit your teeth and gut your way through it (and watch your case)!

Answer 3

Other platforms (e.g. Oracle) do not have a bit SQL type. In which case, it's a choice between NUMBER(1) and a single character field. Maybe they started on a different platform or wanted cross platform compatibility.

Answer 4

I don't like the Y/N char(1) field as a replacement to a bit column too, but there is one major down-side to a bit field in a table: You can't create an index for a bit column or include it in a compound index (at least not in SQL Server 2000).

Sure, you could discuss if you'll ever need such an index. See this request on a SQL Server forum.

Answer 5

The reasons are as follows (btw, they are not good reasons):

1) Y/N can quickly become "X" (for unknown), "L" (for likely), etc. - What I mean by this is that I have personally worked with programmers who were so used to not collecting requirements correctly that they just started with Y/N as sort of 'flags' with the superstition that it might need to expand (to which they should use an int as a status ID).

2) "Performance" - but as was mentioned above, SQL indexes are ruled out if they are not 'selective' enough... a field that only has 2 possible values will never use that index.

3) Lazyness. - Sometimes developers want to output directly to some visual display with the letter "Y" or "N" for human readableness, and they don't want to convert it themselves :)

There are all 3 bad reasons that I've heard/seen before.

Answer 6

I can't imagine any disadvantage in not being able to index a "BIT" column, as it would be unlikely to have enough different values to help the execution of a query at all.

I also imagine that in most cases the storage difference between BIT and CHAR(1) is negligible (is that CHAR a NCHAR? does it store a 16bit, 24bit or 32bit unicode char? Do we really care?)

Answer 7

This is terribly common in mainframe files, COBOL, etc.

If you only have one such column in a table, it's not that terrible in practice (no real bit-wasting); after all SQL Server will not let you say the natural WHERE BooleanColumn, you have to say WHERE BitColumn = 1 and IF @BitFlag = 1 instead of the far more natural IF @BooleanFlag. When you have multiple bit columns, SQL Server will pack them. The case of the Y/N should only be an issue if case-sensitive collation is used, and to stop invalid data, there is always the option of a constraint.

Having said all that, my personal preference is for bits and only allowing NULLs after careful consideration.

Apparently, bit columns aren't a good idea in MySQL.

Answer 8

They may have started development back with Microsoft SQl 6.5

Back then, adding a bit field to an existing table with data in place was a royal pain in the rear. Bit fields couldn't be null, so the only way to add one to an existing table was to create a temp table with all the existing fields of the target table plus the bit field, and then copy the data over, populating the bit field with a default value. Then you had to delete the original table and rename the temp table to the original name. Throw in some foriegn key relationships and you've got a long script to write.

Having said that, there were always 3rd party tools to help with the process. If the previous developer chose to use char fields in lieu of bit fields, the reason, in a nutshell, was probably laziness.

Answer 9

They probably were used to using Oracle and didn't properly read up on the available datatypes for SQL Server. I'm in exactly that situation myself (and the Y/N field is driving me nuts).

Answer 10

I've seen worse ...

One O/R mapper I had occasion to work with used 'true' and 'false' as they could be cleanly cast into Java booleans.

Also, On a reporting database such as a data warehouse, the DB is the user interface (metadata based reporting tools notwithstanding). You might want to do this sort of thing as an aid to people developing reports. Also, an index with two values will still get used by index intersection operations on a star schema.

Answer 11

Sometimes such quirks are more associated with the application than the database. For example, handling booleans between PHP and MySQL is a bit hit-and-miss and makes for non-intuitive code. Using CHAR(1) fields and 'Y' and 'N' makes for much more maintainable code.

Answer 12

I don't have any strong feelings either way. I can't see any great benefit to doing it one way over another. I know philosophically the bit fields are better for storage. My reality is that I have very few databases that contain a lot of logical fields in a single record. If I had a lot then I would definitely want bit fields. If you only have a few I don't think it matters. I currently work with Oracle and SQL server DB's and I started with Cullinet's IDMS database (1980) where we packed all kinds of data into records and worried about bits and bytes. While I do still worry about the size of data, I long ago stopped worrying about a few bits.