I have a large database w/ a bunch of tables and columns are mixed some allowing NULL while others not allowing NULL..
I just recently decided to STANDARDIZE my methods and USE NULL for all empty fields etc.. therefore i need to set ALL COLUMNS in ALL my tables to allow NULL (except for primaries ofcourse)
I can whip up a php code to loop this , but i was wondering if there's a quick way to do it via SQL?
regards
You can use meta data from system tables to determine your tables, columns, types etc. And then using that, dynamically build a string that contains your UPDATE SQL, with table and column names concatented in to it. This is then executed.
I've recently posted a solution that allowed the OP to search through columns looking for those that contain a particular value. In lieu of anyone providing a more complete answer, this should give you some clues about how to approach this (or at least, what to research). You'd need to either provide table names, or join to them, and then do something similar as this except you'd be checking type, not value (and the dynamic SQL you build would build an update, not a select).
I will be in a position to help you with your specific scenario further in a few hours... If by then you've had no luck with this (or other answers) then I'll provide something more complete then.
EDIT: Just realised you've tagged this as mySql... My solution was for MS SQL Server. The principals should be the same (and hence I'll leave this answer up as i think youll find it usefull), assuming MySql allows you to query its metadata, and execute dynamically generated SQL commands.
SQL Server - Select columns that meet certain conditions?
Related
In mysql, the creation statement of query table is as follows: show create table table01.
Now I have a requirement. I want to query the creation statement of a field in this table. What SQL can I use to meet my requirement?
I used Google search for a long time without finding a satisfactory answer, and MySQL official website did not provide the SQL statement I wanted.
I hope a simple SQL statement can make me get the following :
ALTER TABLE `table01`
ADD COLUMN `value` int(0) NULL DEFAULT NULL COMMENT 'value'
Second edit
Thank you for your help. I'm from China. My English is not very fluent. I'm sorry that I don't express myself accurately in some places.
In fact, the reason why I have this requirement is that the project I am currently working on is agile development. The iteration speed between versions is very fast. Often because of the change of requirements, the database tables and fields will increase with it. But I am lazy, and I don't want to record the fields every time I add them. So I use java to make an automation program. At present, it can be compared quickly Quickly find out the differences between formal and test database tables and fields.
But I wonder if there is a better way to find out the creation statement of this field, so that my program looks more perfect.
springboot-mysql-table-field-compare
Snowflakes fluttering north wind rustling(雪花飘飘北风萧萧)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been advised in this self page to not use the wildcard * in my SQL queries.
Wrong query
SELECT * FROM table
instead of
SELECT field_a, field_b, field_c FROM table
I understand only one reason, if you need to know only 3 fields from that query there is no point in force the sql engine to work with all the fields and send them back to your program if you just want to use a few.
But this makes me doubt if is correct to use it if you need all (or almost all) the field data retrieved, or even in those cases it's better to specify all your fields.
Is there any other reason to avoid wildcards than reducing the amount of data sent from the DB engine to the program?
The reason which you have understood is very much valid and is perhaps the most strong reason why it is said so.
In many of the application where the table contains too many columns(lets say 20) and the table size is also huge containing millions of records and if you want to retrieve only specific column then there is no point of using wildcard * as then the MYSQL engine has to unnecessarily iterate though all the columns and all the rows.
But to make a point it is nothing like that * is discouraged infact it can be a boon in the same situation when you have 20 columns and you want to retrieve the values from all the columns.
To add more to it the * could be slower because of the floowing reasons:
In your table you dont create index on all of your columns and the query uses full table scan. So it makes the query slow.
When you want to return trailing fields from table which contain variable length columns and hence can result in a slight searching overhead.
Using * means you're querying all the table's fields. If that's what your application is supposed to do, it makes sense to use it.
If that's not what your application is supposed to do, it's a potential recipe for trouble. If the table is ever modified in the future, the best case scenario is that your application will be querying columns it doesn't need, which may harm performance. The worst case scenario is that it will just break.
I agree with all others that it's not "evil" per se, but I do try and avoid it because of the specific design pattern that I follow. Generally after designing tables, I then create views and join together relevant tables. Finally, I create stored procedures which then select from the views.
I have found that it is problematic (at least in SQL Server) to use wildcard selects in the views and stored procedures. Everything looks good at first, but it breaks down after new fields are added to the source tables. It corrupts the views, and they must then rebuilt to be fixed. Based on the size of the system, this can be a problem.
Since wildcard selects in views cause corrupted views after the source tables are altered, I have started avoiding wildcard selects and will manually alter views after adding new columns to tables.
There is not such a specific reason except following two which are also considered as efficient and optimized method to write query.
You might not need all fields with query so its better to get only required fields will be reduce system load to run query and data will be fetched much faster.
Sometimes we have fields with weird name like lcf_user_email_response which we dont want to use while getting data and showing it on site so to make field alias we use field name not the wildcard.
using field name gives us more freedom to play with fields and output
but there is no such restriction or bad with with wildcard, use them if you need all fields.
I have 2 databases, one mySQL database and a SQLite which sycronize back and forth to maintain the same data. To prevent duplicates on either side I was thinking of having a identifcation numbering sytem for records but im not sure how I will go about that?
I need to somehow create a unique ID for records on both databases, for example:
mySQL ===> data = 1, 5 id=???
sqLITE===> data = 1, 5 id=???
I need the ID to be the same, so when I syncronize it will not transfer over to the other database.
Another way I thought of is creating a hash between 2 columns in the database, and if the same data is on the other server then it does not syncronize that record of data.
Using a column of the database table as a unique identifier is not suitable in my case.
I'm really not sure how to go about this, so any help will be great, thanks!
I understand the question in the way that you need to somehow identify if two rows in two different SQL databases are the same, either because they were independently created or because of an earlier sync.
I think your idea with a hash value is fine. it should do the trick. However, you also could just concatenate the column values in a string and get the same result, maybe with a dash in between in case you have several data columns that would otherwise become ambiguous ("12-2" and "1-12" are then different)
But you still need to send over the generated hash values or concatenated strings of all rows in order to sync. Maybe it makes sense to track rows that are already synced? But then you may need to untrack them if updates of row data values happen.
I am not sure if this answer is helpful to you, because the question leaves many points open to speculation. Can I suggest to make it a bit more clear what you try to achieve?
Let's take a table Companies with columns id, name and UCId. I'm trying to find companies whose numeric portion of the UCId matches some string of digits.
The UCIds usually look like XY123456 but they're user inputs and the users seem to really love leaving random spaces in them and sometimes even not entering the XY at all, and they want to keep it that way. What I'm saying is that I can't enforce a standard pattern. They want to enter it their way, and read it their way as well. So i'm stuck having to use functions in my where section.
Is there a way to make these queries not take unusably long in mysql? I know what functions to use and all that, I just need a way to make the search at least relatively fast. Can I somehow create a custom index with the functions already applied to the UCId?
just for reference an example of the query I'd like to use
SELECT *
FROM Companies
WHERE digits_only(UCId) = 'some_digits.'
I'll just add that the Companies tables usually has tens of thousands of rows and in some instances the query needs to be run repeatedly, that's why I need a fast solution.
Unfortunately, MySQL doesn't have such things as function- (generally speaking, expression-) based indexes (like in Oracle or PostgreSQL). One possible workaround is to add another column to Companies table, which will actually be filled by normalized values (i.e., digits_only(UCId)). This column can be managed in your code or via DB triggers set on INSERT/UPDATE.
Let's assume that you need a table to store settings. For example, I want to store vehicle settings in a table, but there are over 100 settings, so is is better to have a table with 100 columns or a table with maybe 2 columns (1 for the name of the setting and 1 for the value of the setting)?
Either have its advantage and disadvantage.
For flexibility, I would go for Vertical (each setting in each row) approach
If you are using one setting per row,
it will be easier to add new settings or remove unwanted setting in the future without changing the table schema.
You can have an user interface to do this without touching the database
Your clients can add/remove settings without requesting your attention
BUT(s)
You may need to remember the setting keyword, no intellisense
Looping, Cursor
The 100 columns approach
Intellisense
It's just one record, should be faster
No looping, no cursor
BUT(s)
You may have to fill all columns if they are not NULLable
Change schema, you may have to change all dependent codes
I'm all for normalization. So I would create Three tables: Vehicle, Setting and VehicleSetting that will have three columns for vehicle id, setting id and Setting value. Actually I do have this implementation in production. My settings table also has Default Value that is stored if user doesn't specify the value explicitly.
This approach is very convenient if you decide to add a setting in the future. Instead of modifying the table and potentially facing refactoring, you would just add another record to settings table and you're good to go.
I don't disagree with the answer from Dimitri but present the other side.
12 or 100 look at how often to you expect the settings to change.
If each setting is a column then you have a program change for a new property. More simple query syntax. If they are singe value properties then I would argue you still have 3rd normal form and more efficient queries.
If you go with 3 tables as Dimitri suggested then you have a slightly more complex design but you have that ability to add and revise properties run time. The query will be more complex with several joins. You could build a query on the setting table to build your real query. For sure I would use joins over cursor suggested by tcoder.
If you have a .NET or other front end then you could also build up the query by reading from the settings table. If you are binding to like a GridView you will not be able to generate columns but again not that much work.