Member Avatar for kapojian

in my c# program, you will have to create accounts for you to log-in. now, when i create an account, (username, password, age, gender, date...) the info will be inserted in a table named "users". ones a users has a created an account he needs to update his record everyday, look the attached file for example. should a user have a different table? each time someone create an account?

  • 2 Contributors
  • 3 Replies
  • 146 Views
  • 11 Hours Discussion Span
  • Latest Post Latest Post by Fenrir()

Dani AI

Generated

Following ’s scenario and ’s suggestion, the right approach is a normalized design: one accounts table for the user identity and one (or a few) shared tables for the daily monitoring records. Creating a table per person is hard to maintain, wastes schema/metadata, and kills queryability.

Practical layout ideas: keep a single Users table with a compact primary key (an INT identity unless you need globally unique IDs). Put authentication data there (hashed password, last_login, email, roles), but minimize profile fields. Put daily updates into a separate UserDailyMetrics (or UserLogs) table with columns such as Id (PK), UserId (FK), MetricDate, MetricType (or separate metric columns), MetricValue, and CreatedAt. If you only ever need one entry per user per day per metric, enforce that with a uniqueness constraint on (UserId, MetricDate, MetricType) and use an upsert when the user "updates" the day.

Performance and operational tips: index by (UserId, MetricDate) for the common queries, and consider partitioning or archiving older ranges if the table grows into millions of rows. For reads that need the latest status, maintain a small UserCurrentStatus view or table (or use a windowed query) to avoid scanning history. Use transactions for updates and parameterized SQL to avoid injection.

Security and compliance: never store plain passwords — use a modern slow hash (bcrypt/Argon2) and follow OWASP guidance for password storage (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). Also plan a retention/archival policy for historical data and document it for privacy rules. For background on normalization and why a single shared table is preferable, see database normalization basics (https://en.wikipedia.org/wiki/Database_normalization).

Recommended Answers

All 3 Replies

Member Avatar for Fenrir()

Why would they need to update their account everyday? It would be best to use a seperate table yes. Maybe use a UNIQUE Constraint on fields like Email and Username if you aren't doing that already.

Member Avatar for kapojian

i would be making a monitoring system, something like that.. hehe.. but wouldnt it be too much? if every user has a different table? is there a better way than that? thanks

Member Avatar for Fenrir()

I think i misunderstood your question. It will be a very bad idea to have a seperate table for each user. Rather make a general Table and link the user ID to that table. That way you can have multiple users information in one table just like your user table.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.