Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What are the differences between MySQL and Oracle databases. I know both are RDBMS, both use SQL as Query language and both are developed by Oracle. So what are the differences between these two technically?
I used Oracle in Deuth Bank for 1,5 years, and some experience with MySQL on other job.
In general, Oracle is much more powerful and is a deeper RDBMS, which allows you to write any complex system. That's why it is used in banking, military, and science fields.
MySQL - is light, simple RDBMS, it is very well for web, for example small internet shop, your personal web page, or page of a school. More complex web often use RDBMS PostgreSQL.
Oracle allows you to use packages (often on PL/SQL), coursurs (same as subselect), PL/SQL language, Roles, snapshot, synonym, tablespace.
Also Oracle has more advanced data types, and a bit different datatypes.
For example:
BIGINT (8 Bytes) In MySQL, in Oracle called - NUMBER (19,0).
For what I miss in Oracle is select * from dual, wherein dual is a default virtual table in Oracle.
For more deep comparison, please check compare table on Oracle's website:
https://docs.oracle.com/cd/E12151_01/doc.150/e12155/oracle_mysql_compared.htm#i1027526
Mysql and Oracle are both RDMS. oracle not develop MySQL he purchase it.
Both are same just syntax diffrence like
for limit rows in mysql
select * from tbl limit 1
in oracle
SELECT * FROM tbl WHERE ROWNUM <=1;
mysql is open source and oracle is paid.for more diffrence in query you can see here
Related
I've written a POS and back office system, and now after 18 months of customer use I'm looking to improve performance specifically with reporting.
The code is written using CakePHP version 2. I can't find any reference to using additional database indices other than the required Primary key on field "id". The data is stored on Amazon web servers, in MySQL - InnoDB database tables.
Does CakePHP encourage the use of additional indices? I did some background reading on SQL optimisation but I just don't know enough about SQL. With CakePHP there is no need to write any SQL so I'm assuming CakePHP handles all the optimisation itself, or perhaps creates dynamic indices as required.
Thanks in advance.
CakePHP does nothing to automatically add indices to your tables, but your queries will absolutely benefit from doing so. Don't look for information about what will improve Cake's database performance, look for articles about improving the performance of MySQL queries in general.
Turn on query logging to get some examples of the queries that Cake is generating, that will give you things to describe, which articles about performance are very likely to want you to do.
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 3 years ago.
Improve this question
I have about 10,000 data in an old MySQL database written in PHP. This old database has no structure and relationships defined. It's completely legacy design. I'm now working to refactor the entire system of which the tables and their relationships have been completely defined now.
The issue now remains how best to move the data from the old database (written with PHP without framework) to the new (written in Laravel).
Will Laravel commands be a good option where I read data from the old specifying what column is needed and then inserting into the new database?
From the top of my head the following comes to mind:
1. Plain raw SQL
You could write a series of raw sql statements which will read the old database and insert records in the new database. This can be done without the help of an ORM like eloquent.
Advantages:
Nothing beats raw SQL in performance, so the migration will run fast
Disadvantages:
If the database structure is very different it might be hard to write the correct queries
It's easier to forget things like adding primary and foreign keys
2. Laravel commands
You could write one (or multiple) artisan commands which perform the data migration (in steps). This way you can use the DB facade in Laravel to read the old database and use Eloquent to write the data to the new database.
Advantages:
Easier to write as you can leverage eloquent models
Eloquent takes care of things you otherwise might forget like adding primary and foreign keys
Disadvantages:
Raw SQL will probably out-preform the usage of Eloquent.
If you have large amounts of data you'll have to optimize your scripts for memory usage. Otherwise you might run into memory limit issues.
So Laravel commands could surely be a good solution depending on how different your data structures are, how large your datasets are and how important performance is.
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
If i had to develop a
Core Java application which processes CSV files and stored output in a Open-source DB
Data size would be 10 GB initially (porting from existing sources)
Would grow at 1 GB per month
A typical transaction could fetch 100,000 rows
Could be accessed by 1000 users at a given time
And had choice of
Mongodb
MySQL
PostGresql
which would be the best choice of DB ?
This compares MongoDB with MySQL
This compares PostgreSQL to MySQL
Security alerts for MongoDB
With increasing data it's better to have a DB that scale easly and SQL doesn't scale smoothly and eventually breaks doing it, in fact usually for Big Data only High scalable DB are used.
But you said that entries can have correlation with each other so in this case it's better to use a relational DB because the NO-SQL ones can "lose" some correlation.
Like #Craig Ringer said don't consider only those DBs there are a lot of different solutions who has their own pros and cons ( for example redis is very very fast but it's almost without any kind of complex logic because it's a simple Key-Value storage, or Cassandra is faster than Mongo but works better with schemed data, Mongo is a documental DB so can store any kind of data in the same Collection ).
IMHO you should try to set up some bench marking sessions with different DB and Use case and focus on what you want to be done fast and then choose the better in that field.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've recently come across a query which is taking abnormally long time from past few days. We had a server migration for MySQL database last month, and the problem never happened on the previous server. The MySQL version on the older server was 5.1.34 and on current one it's 5.1.58(not sure if that could have anything to do with this issue).
The query is as below:
SELECT table_name,
partition_name,
subpartition_name,
partition_method,
subpartition_method,
partition_expression,
subpartition_expression,
partition_description,
partition_comment,
nodegroup,
tablespace_name
FROM information_schema.partitions
WHERE table_schema LIKE 'wialogdb'
AND NOT Isnull(partition_name)
AND table_name LIKE 'freemail'
ORDER BY table_name,
partition_name,
partition_ordinal_position,
subpartition_ordinal_position;
It's query on information_schema.PARTITIONS
fired by Navicat to get the details about the table structure, it's very difucult to reproduce.
when you edit the table Navicat has to collect all the details abotu the table from Information Schema
(e.g lsit of Engines, Table Columns, see analyze Show Create table, etc)
and PARTITIONS is one of the table it has to check as you can see the WHERE condition is not "correct" WHERE TABLE_SCHEMA LIKE 'wialogdb' it should not be LIKE it should be WHERE TABLE_SCHEMA = 'wialogdb', this query is much more faster, but it's Navicat's internal code
we can not change it. we didn't have this issues in the past (old MySQL 5.1.34)
Any help would be highly appreciated.
Thanks in advance.
If it's not your software, don't try to fix it. Let the creators know you have performance issues and that you have found something which can improve performance.
There's a reason why people buy licenses for software: use the support.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm a bit puzzled to something we got here at the office. We have the same database structure for Oracle and MySQl.
Using Data Modeler we generated the ER diagram of both, and the MySQL DB is missing relationships.
The reason of that, according our DBA, is that those tables are MyISAM to favor full text indexing. But we do use a lot of relations on those tables too, which is why the Oracle version does show them.
Whats right and wrong on our DBs?
I'm not exactly sure what your question is. If you clarify, I'll try and provide a better answer.
Anyway, MySQL has multiple storage engines. MyISAM and InnoDB are two of them (there are others). Each engine has different properties, such as performance, features, etc.
Here's the MySQL docs on foreign keys:
For storage engines other than InnoDB, MySQL Server parses the FOREIGN
KEY syntax in CREATE TABLE statements, but does not use or store it.
and
MySQL gives database developers the choice of which approach to use.
If you don't need foreign keys and want to avoid the overhead
associated with enforcing referential integrity, you can choose
another storage engine instead, such as MyISAM. (For example, the
MyISAM storage engine offers very fast performance for applications
that perform only INSERT and SELECT operations ...).
In other words, if you use MyISAM, you'll have to take care of foreign key checks yourself. If foreign key checks are very important to you, then I would indeed strongly suggest using InnoDB.