Partitioning the table to store the archived projects

[Lavr]

Hello, I am developing the database for one project-management system.
All projects are stored in the table PROJECTS. There can be thousands of projects.
Now I must enable the possibility to make the projects "archived". Such projects are no more visible and changeable.
Is it a good idea to add one field "ARCHIVED" and then split the table in two partitions (ARCHIVED = 0 and ARCHIVED = 1)?
I hope I can get better preformance with such partitioning.
Am I right?

[jkoopmann]

lavr,
having a few thousands of projects in a non-partioned table will not be a problem. you will gain a bit of performance when partitioning and searching for archived = 0/1 since oracle will know that there is partitioning on this field.
really the question of performance is how the data is being accessed to this table and do you have indexes / constraints that support fast access and retrieval of information.

a bit deeper question is if these projects are no longer to be visible / changeable, do you really need to store them any more? or should there be an entity of "archived_projects"?

[Lavr]

Thanks a lot for the answer,

the archived projects must be stored, because they should be visible for some kind of users, and some users can take them from the archive and set back as real projects.
There are some indexes and constraints on the table PROJECTS and they are useful in some cases.
But in cases when the full table scan is unavoidable, such partitioning can help, i think.
The full table scan is needed when the filtered list of the projects is shown, because the projects can be filtered with many different criteria at the same time and the user rights must be checked for each project.