Linq-to-Sql vs CRUD object?

Question

I have a linq-to-sql object from a table. I want to store a similar data in the profile collection. Technically, I don't need all of the data in the linq2sql table and do not really prefer the legacy naming construct. My first thought would be to create a collection of CRUD objects.

But, if I choose this solution I will have double the classes with much overlapping functionality. If I use the linq2sql objects as-is then I'll be dealing with abstractions that contain more data then necessary.

To give you a more clear example, I will create an example that is similar:

This goes into the database and a linq-2-sql abstraction is created

NoteSaved
Date
Id
UserId
Text
....
Custom Methods

This goes into the user profile

[Serializable]
SavedSearchText
Text 
...
Custom Methods

SavedSearchText doesn't need the junk like id, userid, and date, and that data doesn't even make sense for it. But yet the custom functionality will overlap for both classes.

I see 2 trivial approaches:

1. Created a whole new set of objects that are CRUD just for this purpose
2. Use the linq2sql objects as a proxy for the CRUD, i.e using my "wisdom" that these objects are not really "those objects"

I was going the route 1 but see a lot of duplication. It is not very DRY. What are some solutions that keep things as DRY as possible while also maintaining a clear architecture? In other words, I want to avoid having to duplicate the same methods for every object AND I want to avoid storing unneeded data to the profile, such as Ids or DateStored which are not required.

I thought this should be obvious but SavedSearchText and SearchText share a common data field text and common functionality, i.e SomeFunction1, SomeFunction2, i.e FindText.

Edit/Update:

Typically this would be handled with inheritance. We'd have a base business class Text and then 2 derived types SavedText and UserText. But, with linq2sql I do not see a way to do this keeping with DRY principle.

One might also choose to solve via containment via has-a relationship but that is not really not "right" for this context.

Obviously one could create own business layer but that also doesnt keep with dry, as linq2sql has much of the functionality already required.

Perhaps the cleanest solution would be to create CRUD objects but that only read/dump back into the linq2sql objects. Unfortunately, these linq2sql objects will not actually be "tables" and some fields wont make sense. that appears to be the DRYiest solution.

It may even be possible in this case to use advanced methods such as extension methods which would extend both classes but I prefer not to use extension methods unless required.