New answers tagged

1

Run this query: UPDATE tablename SET textname = "" WHERE textname IS NULL after running that you can change the table structure so it does not allow null values anymore. I recommend checking the code to make sure it doesn't check for null instead of empty strings before changing the way the dB behaves


1

Avoiding NULLs is very low on my list of optimizations. I prefer to say "use NOT NULL wherever appropriate". That implies that if you need NULL, go ahead and use it. I do find in my own tables that I rarely have a use case for NULL. See Rick's RoTs for a longer list of recommendations; they are aimed at MySQL, and come from years of optimization ...


2

While I do use NULL columns, there is overhead. The Oracle documentation you retrieved this short list should explain if you read further. There are case where NULL indicates issues with data types and/or just having the column. Consider PHONE_NUMBER NUMBER(15): This will likely have a formatted phone number column, and may be null for numbers like 1-...


1

In Django, you can use models.CharField with combination with a field option choices as it is described at https://docs.djangoproject.com/en/1.9/ref/models/fields/#choices. This solutions is more flexible in case when your logic changes.


4

You want boolean. It can have true (=yes), false (=no) and null (=unknown) More details in the manual: https://www.postgresql.org/docs/current/static/datatype-boolean.html "Avoid nullable columns" is only a recommendation. If you need an "unknown" state, then NULL is exactly what you are looking for. It was specifically created to represent "unknown". ...


0

Does the BIT datatype exist in Postgres land? BIT is the datatype I use in SQL Server when I want to have Y/N/NULL values only.


2

you have a "solution", so by saying I am wondering if there is a better solution. I think you want to comment about it. Let me focus on several aspects: SELECT ID [...] GROUP BY word, independently of having or not a WITH ROLLUP is wrong. You are selecting a field whose value is undetermined. In particular, with MySQL you get exposed of returning a ...


0

The first part of the solution was – as I said in the question – to convert the primary key index into a non-primary index by turning Primary off (and leaving Unique on) in the Indexes window. An alternative means for creating such an index, as suggested by @mpag, is via SQL: CREATE UNIQUE INDEX uidx_engagement ON Engagement (Emp_id, Year, ...


1

I think you need a LEFT JOIN or an inline subquery. The FROM b is also missing. For the NULL to be converted to 0, you need the equivalent of COALESCE() or ISNULL(), which is the Nz() function in Access: SELECT a.partNumber, Nz( (SELECT SUM(b.purchased) FROM b WHERE b.partID = a.partID ), 0) AS sum_purchased FROM ...



Top 50 recent answers are included