A column/field will only have 2 possible values, either "Transplanted" or "Direct-seeding". Is it better to create a table for these options and give them unique IDs or are they better off put as raw string values in the table?
I would start with a check constraint that limits the column to those two values.
If the table containing those values is expected to get really big (tens or hundreds of millions of rows), then using a lookup table and only storing a foreign key reference as a number might save some space and might increase performance if you don't need that value all the time.
Plus it will make adding new values easier because you don't need to re-create the check constraint.
If the end-user is expected to maintain the list of allowed values, then a check constraint is not an option at all.
Another thing to consider is localization (translating those labels). If you have to translate those display values into other languages, then using a lookup table is the better way to go.
Create a lookup table for these two values, with a foreign key in each table that needs it.
A quick example:
create table SeedOrigin ( SeedOriginID int primary key, SeedOrigin varchar(50) ) insert into SeedOrigin values (1,'Transplanted') insert into SeedOrigin values (2,'Direct-seeding') create table Crop ( CropID int primary key, CropName varchar(100), SeedOriginID int ) ALTER TABLE [dbo].[Crop] WITH CHECK ADD CONSTRAINT [FK_Crop_SeedOrigin] FOREIGN KEY ([SeedOriginID]) REFERENCES [dbo].[SeedOrigin] ([SeedOriginID])
If you need to change the spelling of the SeedOrigin you only need to change it in the SeedOrigin table. It is a data change, not a structural change. You would not have to modify a constraint or recompile an app.
This method is scalable in case you need to add more SeedOrigin types in the future, or possibly support other languages.
I'd suggest using a bit field to store the values. Then either allow the application that is using the database to do the work of presenting the end user with the string or just have a case statement in your query to present the string value you mentioned for the true/false condition. If you expect there may come a time that there would be more than two possible values, I'd suggest having a lookup table with a unique id and the strings and referencing them that way.