I'm learning about SQL databases so that I can work on an existing database, and I noticed this naming convention used on a lot of the files.
I'm thinking usp stands for User Stored Procedures, but I'm not entirely certain what parmsel is for. I've tried looking this up and see others using it with the case parmSel...
So what does usp_parmsel stand for?
The files are named like so under Programmability > Stored Procedures in the SQL Object Explorer:
dbo.usp_parmsel_CustomerExists
dbo.usp_parmsel_CustomerReferral
dbo.usp_parmsel_CustomerReceipt
Thanks!
Parmsel stands for parameter selector. You can look up parameter selectors on an engine search machine.
Apparently The PARMSEL field determines the format of the remainder of the area.
There is very vague information about it online.
Maybe this? https://documentation.devexpress.com/#CodeRush/CustomDocument1524
I was finally able to verify 100% with a higher up-- it stands for Parameter Select.
I saw a few places online where this was used, it looks like a rather old naming convention-- which makes sense, I'm working with an old system.
Related
I do not have control of how this data is stored (I know as normalized data would be better for sql), because it is saved via the WordPress GravityForms plugin. The plugin uses a serialized array to define the question id (field_id), question label (label). My goal is to extract these three values in the following format:
field_id label
1 1. I know my organization’s mission (what it is trying to accomplish).
2 2. I know my organization’s vision (where it is trying to go in the future).
Here is the serialized array.
Can anyone please provide a specific example as to how to parse these values out with sql?
A specific example, no. This kind of stuff is complex. If your are working with straight json-formatted data, here are several options, none of which are simple.
You can build your own parser. Yuck.
You can upgrade everything you have to just-released SQL 2016, and hope that the built-in json tools do what you need (I've heard iffy things about them, but don't know what their final form is like. Too, updating all your database servers right now, oh sure.)
Phil Factor over on SimpleTalk built a json T-SQL parser (https://www.simple-talk.com/sql/t-sql-programming/consuming-json-strings-in-sql-server/). It looks horrible and may run poorly, but it would do the needful.
Buried in the comments of that article are links to a CLR tool that John Galt built (at https://github.com/jgcoding/J-SQL). I have used this successfully, though I haven't done anything too complex. (If you're json is relatively simple, this could do the trick.)
There are other json parsers for SQL out there, some free, some for sale. The key thing would be to not try and write your own, but rather find and use someone else's solution that addresses your requirements.
I am fresher and just started learning about database. But one thing strikes me, being a PL/SQL I should know all the data dictionary table, rather than relying on the options given in TOAD, SQL Developer. Like explain plan, search an object, locks, search a text in database and many more which we uses in daily life .
Can anyone contribute the tables or query which we can use in daily practices,rather than just clicking the button in tool, because it's not possible that everywhere we have this GUI interface to work with.
I think this will be very helpful for the people who really want to know what is working behind what option in our buttons.
For Example: The query below is use to search the string in all the database objects
Select *
FROM DBA_SOURCE
WHERE text LIKE '%<your text >%';
You are right: developers (and wannabe DBAs come to that) should know the Data Dictionary, rather than relying on an IDE. A good Oracle practitioner should be able to survive with just a text editor and SQL*Plus.
There are too many views to understand them all. You just need to know that they are all covered in the documentation. Find out more.
there are many different uses of the data dictionary from querying package sources, to database administration.
Burleson has a few here to get you started
http://www.dba-oracle.com/concepts/data_dictionary.htm
You can get a good list from the following select statement:
select table_name||': '||comments from dictionary;
That lists 838 rows. The ones you would use most are probably ALL_OBJECTS, ALL_TABLES, ALL_TAB_COLUMNS, ALL_VIEWS, ALL_SOURCE, ALL_COMMENTS, and (sometimes very important) ALL_SYNONYMS.
ALL_SOURCE is a good place to find documentation for Oracle's built-in packages, because the comments in the package specification tell you everything you need to know to use them. For example, look at DBMS_SQL.
I am looking for a performant default policy for dealing with the .dbo prefix.
I realize that the dbo. prefix is more than syntactic noise, however I got through the past 8 years of MS based development skipping typing the dbo. prefix and ignoring its function.
Apart from a performance issue with stored proc compile locks is there a downside to skipping typing ".dbo" in SQLqueries and stored procedures?
Further background: All my development is web middle-tier based with integrated security based on a middle tier service account.
[dbo].[xxx]
The SQL Server engine always parse the query into pieces, if you don't use the prefix definitely it going search for object in similar name with different users before it uses [dbo]. I would suggest you follow the prefix mechanism not only to satisfy the best practices, also to avoid performance glitches and make the code scalable.
I don't know I answered your question, but these are just my knowledge share
Most of the time you can ignore it. Sometimes you will have to type it. Sometimes when you have to type it you can just type an extra '.':
SELECT * FROM [LinkedServer].[Database]..[Table]
You'll need to start watching for it if you start using extra schemas a lot more, where you might have two schemas in the same database that both have tables with the same name.
The main issue is not security, is name conflict resolution, in the case that your application will ever be deployed side-by-side with another application using the same names in the database.
If you package and sale your product, I would strongly advise to use schemas, for the sake of your costumers. If you develop for a one particular shoppe, then is not so much of a concern.
Yes you can ignore - for the most part - if you never ever create anything outside the (default) "dbo" schema. One place you can't ignore it is when calling a stored function - that always has to have the "two-part" notation:
select * from dbo.myFunc
However, it is considered a best practise to always use the "dbo." prefix (or other schema prefixes, if your database has several schemas).
Marc
"however I got through the past 8 years of MS based development skipping typing the dbo. prexfix and ignoring its function."
This is your answer. If your DB is performing fine you are OK. Best practices don't replace real testing on your actual system. If your performance is fine and maintenance is OK, your time is better spent elsewhere where you can get better bang for your proverbial buck.
After working in the oracle world, I would advise against skipping the schema declaration. Remember now that SQL server versions after 7.0 support multiple schemas per database - it is important to distinguish between them to be sure that you are grabbing the proper tables.
If you can ensure that you'll never have two separate schema namespaces per database, then you can ignore it. The dbo. prefix should do nothing to affect performance by itself - parsing is such a small part of the SQL query as to be insignificant.
Exists any naming guideline for naming columns at Sql Server? I searched at MSDN, but dont found anything, just for .Net
There are lots of different conventions out there (and I'm sure other answers may make some specific suggestions) but I think that the most important thing is that you be consistent. If you are going to use a prefix for something, use it everywhere. If you are going to have a foreign key to another table, use the same column name everywhere. If you are going to separate words with underscores, do that everywhere.
In other words, if someone looks at a few tables, they should be able to extrapolate out and guess the names of other tables and columns. It will require less mental processing to remember what things are called.
There are many resources out there, but nothing that I have been able to truly pin down as a SQL Server specific set or anything published by Microsoft.
However, I really like this list.
Also, very important to NOT start out stored procedures with sp_
To be 100% honest though, the first part of my posted link is the most important. It must make sense for your organization, application, and implementation.
As always, google is your friend...
I find the following short list helpful:
Name tables as pluralnouns (or singular, but as a previous response stated, be consistent) for example "Customers", "Orders", "LineItems"
Stored procedures should be named without any prefixes such as "sp_" since SQL Server uses the "sp_" prefix to denote special meaning for system procedures.
Name columns as though as you would name attributes on a class (without using underscores)
Try not to use space characters in naming columns or database entities since you would have to escape all names with "[...]"
Many-to-many tables: for example "CustomerOrders"
We're looking to encrypt a field using DB-side encryption via NHibernate (most examples we've come across are app-side, which is not what we would like). The issue has been raised a couple of times, but no answers yet it seems.
On SQL Server 2005, for instance, and forgetting key-related issues for now, this means INSERTing EncryptByKey(Key_GUID(MyKey), MyValueToEncrypt) and SELECTing DecryptByKey(MyEncryptedField). The property might be a string, whereas the field has to be a varbinary.
We've vaguely got somewhere - using upper() and lower() instead of encryption functions - by combining paired properties, one mapped with a custom user type and the other with a formula attribute.
However if anyone has any ideas on how to do this in a nicer way, we'd be most grateful for a few pointers :o)
Posted outline of nasty hack on the NHibernate forum
There is a project on SourceForge, MindLib, that has useful NHibernate utility functions and libraries. One of those is an EncryptedString library which allows you to store an encrypted string. Unfortunately, this is not doing it on the server side, as you originally requested.
I've been looking for something similar. The only thing I could come up with is to create a User Function in SQL Server to encrypt the string. Something like this.
MindLib EncryptedString
thanks for the feedback! We're keeping the MindLib approach as a last resort because it effectively displaces data ownership from the DB to the app. As far as we can tell, TDE-enabled DBs (say SQL Server 2008 or Oracle 10.2) make the problem go away, but not all our customers are willing to splash out on upgrades ;o)