Tag Info

Hot answers tagged

4

Sure you CAN do it, but why would you? To save a few CAST expressions? That seems a bit weak. The reasons to have auto incrementing surrogate int PK's are many: You pretty much never have to manage them with normal databases. Ever. Unless you are rebuilding tables or inserting data where you have to turn the identity off and on. But operationally it works ...


3

Use mysqli or PDO libraries for PHP, do not use mysql, as it is deprecated Use prepared statements: they are cleaner, less prone to SQL injection and, in some cases, faster to execute Use exceptions to capture errors throughout your code -query fails, query gets killed, database crashes, unable to connect, ... If you feel intimidated by SQL, an ORM can help ...


2

This would most definitely not be preferred to an auto-increment integer field. For starters: Index width would be degraded significantly with your proposal. Just how do you propose to manage all those random 2-digit integers to enforce uniqueness. Have you thought of how much code would have to be written and maintained to implement this scheme. Won't ...


2

Clearly you need a "Competitor" table if you wish to represent them, which I assume you do! Competitor Name, Age, Sex, Contact etc. Personally I would create a new table called "Discipline Type" which would differ from "Race Type". The two are functionally independent - race type could be "Triathlon" while "Discipline Type" could be ...


1

Pattern matching and operators Full text search is not the right tool for pattern matching (and possibly even fuzzy, fault tolerant input). Typically, trigram-similarity search with the % operator is the superior approach here. You need to install the additional module pg_trgm once per database: How do I create an index to speed up an aggregate LIKE query ...


1

Start with: Create a ChartOfAccounts table with the Account code as Primary Key. Add a Foreign Key constraint to ChartOfAccounts on all tables with an AccountCode field. Use an IsDebit field, not the numeric sign, to distinguish Debits from Credits and reserve negative signs for transction reversals (if used at all). This is necessary in order to generate ...


1

Jeff Moden has written two excellent articles on SQL Hierarchies here (Hierarchies on Steroids #1) and here (Hierarchies on Steroids #2) which present efficient SQL algorithms for converting hierarchies stored as an Adjacency List (ie children have a Parent pointer - easier to visualize and more efficient to create) to a temporary table organized as nested ...



Only top voted, non community-wiki answers of a minimum length are eligible