At the point where you are interfacing with the database, your code should be general purpose and reusable. A class like this should -
1) As already mentioned, use the php PDO extension. In addition to letting you use the same php statements for any of the database types that PDO supports, this will simplify the code, since you don't need to explicitly bind inputs and the PDOStatement object is the same regardless of how you execute the query, so the code dealing with the result from a query can be consistent throughout an application.
2) Also, as already mentioned, you should use exceptions to handle database statement errors (connection, query, prepare, and execute - you currently don't have any error handling beyond the connection), and in most cases let php catch the exception, where it will use its error_reporting, display_errors, and log_errors settings to control what happens with the actual error information. For the cases where your application should handle the exception, it is your application code that knows what to do when there is an error, such as for a duplicate value being inserted/updated, and the error handing should be in the application code, not in this interface class.
3) Extend the base class with your interface class. This will let you use the properties and methods of the base class without needing to write wrapper methods. Keep It Simple (KISS) and Don't Repeat Yourself (DRY) by not writing extra code that duplicates functionality that already exists.
4) You need to supply the connection credentials as call time parameters when you create an instance of the class, with the same format as the base PDO (or mysqli) constructor definition. This will let you create multiple connections and deal with multiple database types in an application WITHOUT needing to edit/re-write values/code in the class.
5) Your ->get() query method should only execute a prepared query if there are inputs being supplied. If there are no inputs, just call the ->query() method.
6) It can be a problem in real applications to explicitly bind inputs for a prepared query, as this limits numerical values to PHP's maximums, which can be less than your database's definition and capabilities. It is best to treat all input values as strings and let the database engine parse the values to numbers. With the PDO extension, you can just supply an array of input values when you call the ->execute() method. All values supplied like this are treated as string data.
7) For any SELECT query, it is your application code that knows how the data should be fetched -
a single column from a single row, a single whole row, one column from a set of rows, or a set of whole rows, all either as an array or an object. The ->get() query method should not fetch any data, just return the stmt handle to the calling code.
8) Insert, Update, and Delete queries can affect more than one row. The code in this class should not be trying to test the number of affected rows. It is the application code that knows what type of query was executed and if exactly one row or more than one row should have been affected. Once you remove the affected rows logic from the CreateAndUpdate() method, you will see that the code is the same as for the ->get() query method and you should instead have one single general purpose query method that can be used to execute any type of query.