Opened 11 years ago

Closed 6 years ago

#531 closed improve feature (wontfix)

table column 'cryptedfields.TableColumn' - fill it with content!

Reported by: lemon-head Owned by: jeanyves
Priority: major Milestone: unassigned
Component: BW Database Keywords: cryptedfields tablecomumn
Cc: lemon-head

Description

Currently the cryptedfields table has a column named 'TableColumn?', which should point to some column in members table. For now (on my localhost) this column only says "NotSet?".

I would like if we can fill the column with content (the name of the table column). In the end, this will help us to make more efficient DB queries, getting all the crypted fields at once.

The combination of IdMember? and TableColumn? will be enough to find out what the crypted field refers to. In the end we can remove the columns from the members table, they will be no longer needed.

Change History (4)

comment:1 Changed 11 years ago by jeanyves

  • Cc lemon-head added
  • Keywords cryptedfields tablecomumn added
  • Owner set to jeanyves

NotSet? is use to mark the records which don't have content

I am working on this (and in fact I have already included some way to autofix them, if you notice, they are new InsertInmemberTrads? functions)

About removing the members.IdForeign_to_some_record_in_crypted : this is a bit the idea I have, but my initial concern when I added this column was to have a way to detect orphan record.

One thing also, (@Andreas before you say it ;-) ), the TableColumn? will be far more efficient when it will be either an enum with the various possible values or a foreign key to some other table TableColumnPossibilities? which will contain the possible values for this field.

Last thing : I have made a routine which detect the value with NotSet? and which can fill them with the appropriated members.IdXXX value (this to manage the redudancy)

comment:2 Changed 11 years ago by lemon-head

One thing also, (@Andreas before you say it ;-) ), the TableColumn?? will be far more efficient when it will be either an enum with the various possible values or a foreign key to some other table TableColumnPossibilities?? which will contain the possible values for this field.

I don't know if it is really more efficient. What I would usually do is

  • load ALL crypted fields for one member, into an array
  • then use php to find out which crypted field to use where.

With a separate crypted_field_names (or table_column_possibilities, as you say), the SQL lookup will be more complex, because it will need a combination of tables.

Another situation is when we only want ONE crypted field. Then it could be more efficient with a second table - or not?

About table structure cleanliness, I am really not sure this time - I think both would be "allowed" :)

comment:3 Changed 6 years ago by jsfan

  • Milestone Future deleted

Milestone Future deleted

comment:4 Changed 6 years ago by planetcruiser

  • Milestone set to unassigned
  • Resolution set to wontfix
  • Status changed from new to closed

the whole crypt idea will be dropped

Note: See TracTickets for help on using tickets.