one to many without foreign key I know this is kind of a beginner question.  I am maintaining legacy code and data and just have to deal with the way things are  But if you were to design a new database from the start - is there any legitimate reason to create two tables with a one-to-many relationship in Microsoft Sql and not use a Foreign Key?  

We currently are not in some tables and the reasons to not implement them now make sense , but none of the reasons are really sufficient to explain why the keys were not implemented originally
There are several legitimate reasons not to actually create a FOREIGN KEY constraint on a foreign key relationship:


In some cases, you may not be able to - for example, if the other table is in another database.
If your database was migrated from another environment, you may already be maintaining the relationship via triggers. In the best of all possible worlds, you'd switch to an actual foreign key constraint; however, when you have something that's already working, making changes that don't add anything of immediate and obvious benefit is a hard sell with your bosses.
Due to complex business rules, you already have to maintain the relationship with a trigger. You might be able to have the foreign key relationship defined as well, but having it defined in part in two different places is not necessarily a good idea.
Extremely frequent data load tasks that can be done faster/easier without foreign keys being on. It's possible to add code to a script to drop and recreate your foreign keys (or disable and enable, whichever), but if this is happening on a daily basis, and is the source for most of your data, there may not be much of a point in actually having the foreign keys.


Note: In all the above cases, I would have something in place (usually triggers) to maintain the foreign key relationship properly.

There are also less legitimate reasons not to have actual foreign key constraints in place:


The database was migrated from an older system that did not have foreign keys, or where using them was impractical;
The system's developer didn't know what they were;
The system's developer did know what they were, but didn't understand how to implement them properly, and found that they caused errors (because the system didn't bother to create ways to add new values to the other table, etc.).


In the first of these cases, other mechanisms (triggers, application code, etc.) may be in place already to maintain relational integrity, and adding the foreign key could again leave you with two different mechanisms in use at once, which can make things very messy.

In the latter two cases, the biggest impediment to adding the foreign key constraints immediately is that you will start having errors until you've ferreted out and fixed all the places where the original developer may have been ignoring nor bypassing the relational integrity.