text:
NEW BEDFORD — "Freedom is not free" was the message at the National Vietnam Veterans Day memorial service held at Fort Taber Sunday, during which Nelson Ostiguy was honored with a public service award.
NEW BEDFORD — "Freedom is not free" was the message at the National Vietnam Veterans Day memorial service held at Fort Taber Sunday, during which Nelson Ostiguy was honored with a public service award.
"I would like to present this on behalf of Chapter 499 of Vietnam Veterans of America in recognition of your commitment to acquiring a commemorative plaque in memory of Lance Corporal Micheal L. Ford who gave his life in Iraq," said Dan LeBlanc, veterans agent for the city. "Nelson is the one who bought that plaque out of his own pocket. When I heard that, I went to my guys, and there was no way we were going to let him do this on his own. I think as a result of that, we raised enough money so that Nelson did not have to pay out of his pocket. We wanted to do this as a community and the city of New Bedford, and for that we are all grateful to Nelson Ostiguy."
Mr. Ostiguy, an aide to Mayor Scott W. Lang, was in the Marine Corps during Vietnam as a team leader for a reconnaissance unit.
As a state police officer, he received two American Legion certificates of commendation for outstanding service. The first was for apprehending three armed robbers as they attempted to flee on a highway, and the second was for when he rescued a kidnap victim in Brockton. After receiving the state police Meritorious Service Award, he retired in 1996 as commander of the Division of Investigative Services.
Barely holding back tears, Joseph Ford, the father of Michael Ford, presented Mr. Ostiguy with two gifts, an American flag tie and a statue of an eagle.
"(Mr. Ostiguy) was the driving force behind my son getting his plaque up on City Hall," Mr. Ford said before the ceremony.
The award was a complete surprise to the man who says he keeps to the background and usually sweeps the floor after such events.
"I am truly, truly humbled. I am so proud to get this from you folks. I will cherish this forever," he said.
Lance Cpl. Ford's mother died before his being sent to Iraq, so two women from the New Bedford chapter of Gold Star Mothers were present to represent the mothers who have lost children in the service.
"It brings back too many memories," said Mary Daggett, who lost her son, Sgt. Joseph Paulette, in Vietnam.
Louise Pina, president of the chapter of Gold Star Mothers, sat quietly with a picture of her son, Lance Cpl. Luiz Pina Jr., who was killed at Chu Lai.
Mayor Lang, Rep. Antonio F.D. Cabral, D-New Bedford, and other officials spoke at the event.
"I think you can judge a people, country, a community by the way they honor their veterans. This administration, the City Council, and our city legislative delegation believes very firmly that we must at all times appreciate the men and women who serve overseas and the fallen and the young men and women who come back to our country and their families," Mayor Lang said.
"We are a country at war right now. We have just passed the 4,000th man or women who has given their life for freedom. And again, what we should be doing is thanking God that there are men and women like that who are willing to risk their life or give their life for us."
Rep. Cabral spoke on the importance of honoring veterans regardless of one's political opinions.
"We can agree or disagree (with a war) — that is our freedom. But we must support the troops all the time."
During the ceremony, the City Council announced that it would be moving ahead with a memorial to honor the women who have served.


text:
What better way to take advantage of the British summertime and boost morale than to mingle with your colleagues at a spectacular summer celebration!? Let's make the most of the sunshine and harness all that positive energy with your very own Corporate Barbeque, or perhaps you prefer the sound of an Enchanted Garden Party to entertain your guests - we're picturing cool crisp drinks in hand, mouth-watering barbeques and decorations to delight… the possibilities are endless! Whether you're looking for an outdoor event (Day at The Fair did I hear you say?), evening soiree (hello private Rooftop Party) or fully Themed Party we've got it covered. Want to get the kids involved too? How about a Family Fun Day, complete with your own giant garden games (the big kids among you will enjoy these too!), waffle kart and bouncy castle, of course not forgetting some delectable food to tantalise the taste buds!
Here at Eventa we love what we do and if we do say so ourselves, we're pretty good at it too! So if you're going to throw a corporate summer party this year and want an experienced events agency that care, then book with us as we pay special attention to each client and put our hearts into the details of each party. So you can rest assured that you'll be booking a high quality event that will be memorable, enjoyable and impressive!

subset: commoncrawl


text:
The ever-insightful Buck Woody (Blog – @BuckWoody) wrote a post telling you to use database schemas. He writes:
"But I still see a lot of applications, developed by shops I know as well as vendors, that don't make use of a Schema. Everything is piled under dbo…. But if you'll use them properly you can make your application more understandable and portable."
I disagree – and Buck and I started a conversation on Twitter which quickly turned into a group discussion. It merits more than 140-character comments, but since Buck's blog temporarily has comments turned off, I wanted to give people a place to discuss.
My thoughts: schemas are naming conventions in lipstick. When I look at somebody's code, the last thing I ever think is, "Man, if these tables just had schemas, I could understand everything better." In fact, when I see objects broken up into different schemas, I usually end up asking questions like, "Why are we writing user reports against something in the ETL schema?" The answer comes back, "Well, it used to be an ETL table, but then our needs changed, and we couldn't rewrite all our code, so it just turned into a production table." Great.
If they're used right, they let you segregate permissions by groups of objects. But here's the thing – almost nobody ever does that. It's more work than it's worth except in the largest of databases. When we're talking about a vendor app that gets sold to third parties, you usually don't want anybody jury rigging permissions together – just query through the app like you're supposed to, and keep your filthy hands out of my database.
91 Comments. Leave new
Great post Brent, as always.
I think they help me in two ways – I segment the information into logical containers (which, by the way, are easily transferred if things change) and I can set the permissions on the schema without knowing if the end-user shops are fond of roles, users, Windows auth and so on. I document these permissions and let the end DBA decide how they want to handle it.
(Cause I'm good like that.)
Thanks, sir! I gotta drill down into that though.
How specifically are they "easily transferred if things change"? I don't understand how it's easier to transfer objects by schema than if you used a naming schema for objects, and if they've got foreign keys that cross schemas, you're still out of luck.
When you say "let the end DBA how they want to handle it," if you're really writing an app for wide distribution and frequent upgrades, why would you want the DBA to go in and change permissions? That's a recipe for a broken app.
I see your point there – missed the part about the FK's. As far as perms, I guess it all depends, right? All I meant was that the end DBA can assign owners and default schemas – they don't have to mess with the actual perms themselves.
Some shops I see user roles heavily, others use users, some are Windows auth, some even change the db user name from the Instance login (!) so this lets me not worry about that.
Does that make a little more sense?
But if you don't know the end DBA, how can you predict how they would want the objects organized into schemas? You're still guessing based on what YOU think the DBA wants. It'd probably help me understand if I heard a story from a DBA who said, "I inherited this database from a vendor, and thank goodness the objects were broken up into schemas, because I was able to ___, which I couldn't have done otherwise." I don't see a lot of DBAs tackling third party app databases and making changes.
That's because you keep encrypting the stored procedures. Sorry, couldn't resist.
HAHAHA, honest to God I was thinking about that when I wrote it too!
Forgive my ignorance, but how are FK's affected by schemas? I need more details b
Oops hit enter by accident.
I need more details because I must have a gap in my understanding of schemas.
Somebody (probably Buck) likened schemas to folders on your hard drive. So following your thought, do you shun folders, and just name all your files with prefixes?
I see a lot of merit in the security argument, but equally appealing to me is the organization/grouping factor.
No, I use *databases* for that. When I have applications, I separate them into databases. If I have dramatically different projects, then I probably want to have different recovery options and maintenance options for them. Schemas takes that ability away from me.
So let's take a simple sales application:
you need to track data in high level areas, such as inventory, customers, orders, security, a product catalog, and probably some set of tables that are simply there to support the application (logs, etc)
you have a few options:
1) naming conventions
2) seperate databases (?!?!)
3) schemas
we don't want these in seperate databases due to RI. we want to make sure orders refer to actual products, and made by actual customers, and that our inventory contains actual products.
as far as naming conventions vs schemas, i suppose the difference in many cases is simply '_' vs '.'
(though one downside to schemas is the existance of only one level of grouping)
however, with schemas you can quickly assign permissions, for example: the users responsible for orders can, by default, have read only permissions on everything else. other users can be seperated by area of responsibility.
it's not the schema's "Killer App" per say, but for me, i organize schemas as above in nearly every db i create. it just makes things simple.
also: i can grant execute permissions on the appropriate schemas, and then i don't have to remember to add all roles with execute permissions to each new proc that gets created 🙂
I have to agree with Brandon here, schemas do two nice things for me when I'm building out a database:
1) They allow me to group my objects together and organize them easily (I suspect that this argument is more a matter of design style than right vs wrong)
2) They make it easier for me to grant exec to my sprocs by doing so at the schema level instead of having to do so for every sproc I create.
To be honest, the concept of Schemas in SQL Server has always confused me.
I look to FKs to figure out how objects are related. The security thing is interesting…but seems like more work for little return?
I agree with Buck that schemas, in a perfect world, would easy our lifes making all the related tables being part of a nice container..
but in the real life the permissions benefit are not in fact a benefit 'cause 99% of the vendor applications uses 1 sql or windows user to all DB access and the few databases that do use schemas have those problems of tables that shouldn't be in the XYZ schema.. but it is 'cause the effort to change the code to point to the new schema is too big.. off course.. this is DBA fault that didn't did a good DB design in the first place.. but this is the industry reallity..
ah.. and one more thing.. no one here ever saw databases where we have more than 1 table with the same name but in different schemas? and a lot of queries in the wrong table 'cause the DEV didn't correctly specified the schema name..
ow my…. sometimes I do hate developers..
I don't see permissions in schemas as any different than a role. They can organize things, but when code changes, and needs change, which seems to happen often, you don't want to move objects from under the schema to a new one, especially if you have code referencing the schema.
I never saw an issue in SQL2K using dbo as the default schema for everything, and I'd argue that having the same table in two schemas can be confusing.
The exception might be with ETL work where you stage data, and it arguably is clearer to have ETL.Orders and dbo.Orders
I use schema's (in a warehouse environment) to provide a layer between the users… which access everything through the default "dbo" view's that point to the underlying tables in a schema.
Provides several things…
Blogged on this one a few weeks ago:
1) "fix" things in view with joins/case statements etc until permanant changes can be made to ETL/historical data, tables etc.
2) Point the view to a copy of the table while you do maintenance, repartition, compress, etc etc …. and your users don't even know it is happening.
3) Who wants columns in alphabetical order… one of my users does…
4) Security… if you have significant security needs your views can point to multiple schemas each secured independently.
Stef – interesting, but I don't understand why you can't accomplish that in a single schema. You could put all of these objects in the dbo schema and it'd work fine. If you're saying you have the same object name in different schemas, and you use the same select statement but you select the right one based on who's logged in, that's a troubleshooting mess.
No.. not same object in different schemas…I agree that would be a MESSSSSS but…
The table-name (and the view-name in dbo) do match. So when someone does the dreaded "select * from test" I get to control what they see from where, in what order etc.
(This does not work….same name cannot exist)
CREATE TABLE dbo.test
(test_col INT)
CREATE VIEW dbo.test
SELECT test_col
FROM dbo.test
(assuming dw_dbo schma exists… this does work):
CREATE TABLE dw_dbo.test
(test_col INT)
CREATE VIEW dbo.test
SELECT test_col
FROM dw_dbo.test
Thus you can point the view to dw_dbo.test2 or whatever you want while you work on the dw_dbo.test table, and users are not affected.
Whoa – you're recommending that people create multiples of the same object name as tables and views plus in different schemas, and then use them without prefixes? How on earth do you troubleshoot queries in the procedure cache? You can't tell what object they're actually trying to access without doing a ton of work. That strikes me as a total nightmare, and I would neeeeever want to recommend that to anyone. Are you saying you actually encourage people to do this?
OK… your taking this too way far! …. this is VERY tightly controlled, with the ONLY access by way of the dbo objects (views). The ONLY time I swap out objects is during maintenance that can't be done off-hours, or during the implementation of a new table/feature. All views point to the underlying tables at all times, thus all queries are reading from objects named the same as the underlying tables. Load processes ALL access the tables, thus the tables MUST be there for the loads to run daily…NO insert/update etc is performed through a view ONLY to the object with the schema prefix.
The queries in proc-cache, plans etc are still valid… don't missunderstand the flexibility I am talking about as something to flip-flop tables around and leave them pointing to different objects…. that is NOT what I am advocating at all.
I am NOT suggesting multiple schemas (with the excpetion of the possible need for security reasons… and even then…. not sure) I am advocating 1 schema for the warehouse data tables that is not dbo.
I think we actually agree…. I fear I am just not making myself very clear.
I use schemas to control security access to the underlying tables. Things that anyone can access goes into dbo. Procedures, views, and functions specific to a single application go into a schema. I create a certificate with the security for that schema and then I create a user from that cert.
Typically, I only key from a custom schema to dbo. We do a lot of design before we create tables in the database (mainly by yelling over the cube walls). If there's even a thought that something will be used by multiple applications the table goes into dbo but we put the sprocs and views into a schema.
As someone who sits on both sides of the fences, developer and database designer (as well as BI guy and bottle washer) I like schemas. If nothing else when working with a large database it's much easier to find tables I need when writing stored procs, views, reports, and classes if things are organized into schemas. And while it's true it's not done much, we have actually used the to control permissions on a few projects.
Scary story, we had an app that had been running fine, then one day it just broke. After half a day of phone calls, etc, we finally tracked down why. A junior DBA had been doing maintenance on an adjoining database and for whatever reason looked at our production database. He'd never seen anyone use schemas before, assumed we were idiots and on his own changed them all to dbo.
I've seen the extremes. Databases with horridly complex naming conventions and even more unmaintainable permissions, all the way to multiple databases with 10 – 20 tables each for a single application. I think Schemas would have been useful in both cases.
Overall, I see schemas as an added layer of granularity. They're there to be used when needed. They may not always be needed but there are certainly cases where they would be very appropriate, and not just for security. What about breaking out schemas into different filegroups for a performance benefit?
"10 – 20 tables each for a single application" — stop working on mom and pop applications and try working on real applications. Any serious application will have a LOT more tables.
The biggest problem for me is that because schemas had been lacking in SQL for so long, it is really hard to argue that we really need them however….
When performing script deployments on the dark side (Oracle) I find the use of schemas as a very good safety net. Since the schema user does not have permission outside of the schema, this prevents problems being very big problems since the change is encapsulated by the schema.
The other issue we have is that the SQL database is incredibly accessible, this is primarily down to Windows authentication which means that connection to any instance from any tool is VERY quick. This encourages us to login using our privilege user account rather than authenticating with just the right amount of permissions that we require for that operation. That surely has to be better practice right? Conversely connection from Oracle clients are a real pain and usually encourages the entry of user/password thereby making it logical to enter the schema user.
There are certain things like this (schemas not poor authentication!) in Oracle that we as dbas or developers could adopt which could only strengthen SQL's excellent Enterprise credentials.
Another reason the Oracle dbas like schemas is that it does allow for them to treat the schema and its objects as one interdependent unit. This is particularly useful for data refreshes and the like.
Finally, I believe another reason why schemas haven't really been adopted in SQL as opposed to Oracle is that in many ways SQL server databases are probably more comparable to Oracle schemas and therefore we could probably get by without them. Oracle would struggle.
In conclusion in the right situations the adoption of schemas should (imo) by encouraged, but like everything if they are implemented incorrectly in SQL Server it is only going to cause more overhead for the dba.
I don't buy your argument. In your example, just because whomever was in charge of that schema was too lazy to properly refactor it when the purpose of the formerly-etl table changed doesn't make schemata a bad idea. Schemata do make things like permissions management easier. Riddle me this: when you have a database with even 100 stored procedures, what's easier:
1) Remembering to grant permissions on each procedure to all the users/roles that need it?
2) Granting that permission to the schema once and forgetting about it?
I know which one I prefer.
Ben – I only grant permissions once. I create roles in the database that match what my end users need. When people come on board, I add them to the appropriate roles. That way I don't have to touch any objects directly. When I add new objects, I grant the role the right permissions. You never, never want to grant 1:1 permissions between end users and objects.
That's not what I'm suggesting. Even if you use roles, you're still granting object-wise permissions. So, when you add that 101st stored procedure, you have to remember to grant execute permission to that same role. Yes… you can get around this by having a template for your procedure DDL, but why go through the hassle? If you could run one grant statement that not only covered your current needs but your future ones too, my question is: why wouldn't you do that?
Finally (!!) someone used the proper plural.
I'd use schemas for:
1) developers to have playgrounds
2) caching other databases locally
3) application support of a second set of rules (such as a reporting schema)
4) Snapshots, when consistent snapshot is required, and the data model does not
support it.
5) Copy and paste a schema to test new development.
1 and 2 allow unhindered naming schemes.
3 and 4 usually go together.
I would not use more than one schema for the same data model. There'd be no way to
support option 5. Besides, a schema can handle a model.
To separate objects in the schema, i use prefixes on the TABLE names.
IMO, using schema TO make permission-management easier, is a hack.
Brian – in all of those instances, why wouldn't you use a separate database? All of the scenarios you describe should have a different recovery model, high availability strategy, and so forth from your production database.
If you're putting dev/cache/snapshot data inside the production database, I can see why schemas would be attractive, but I'd make the recommendation to avoid doing that in the first place.
Here's what i am thinking.
For 1 and 5, the user can simply change the schema being referred to, and things run the same. They can even change the schema on only some of the TABLEs. (I do this all the time when hacking one TABLE for testing, but do not want to hurt anyone elses development. CREATE SYNONYMs in a new schema to point to the real TABLEs, except the one i want to hack at.) Changing databases requires more statement to be run, or fully qualified names.
For 2, it's another corporate database being stored locally. We cannot trust them to always be up, or not to change anything. So, based on the time granularity we need, just pull another snapshot. To give it its own namespace, go a level up to a schema. Though i guess a database is an option, but it seems like overkill.
Recovery? Points i never thought of that. I come from Oracle where switching schemas is easy, but databases is harder. I don't even think of using another database unless its something completely different.
I guess another point is databases can be taken offline. Schemas cannot. So, if my code is running in one schema, the other schema is available. The same assumption cannot be made for another database.
We're using schemas at my job for several different reasons.
We give each database/application a unique schema because we just don't care to have everything sit in dbo. We generally use dbo for temporary objects that we are testing with.
We also have several other schemas, such as log, staging, rs, cg, etc. log is for any logging tables. staging is usually for importing data from old systems (ie, access, excel, etc) to then transform into the new system. rs is for Reporting Services objects (mainly stored procedures). and cg is for code generated stored procedures. we have an app built inhouse that runs against a database and creates crud procedures for each table that are then used in the application.
Thirster42 – okay, that's interesting, but what do you *accomplish* with the different schema names that you couldn't accomplish with naming prefixes instead?
i can set security on a schema level. So if x,y,z should be able to read and write schema a, then i set them up on the schema (or if i was smart i made a role assigned to the schema and assigned them to the role). if you just used a table prefix then you have to specificaly select those objects in the role, and new objects aren't automatically added (which could be either a good or bad thing depending).
Also, I hate table prefixes. I prefer real words for table names. I'd rather write log.Employees instead of dbo.logEmployees (which is also longer :-D).
also, x,y,z would (if we were following our internal standards) actually be in an AD security group.
on the flip side though, you can see schemas as simply an extension of using naming conventions, but with a small amount of additional functionality (specifically quicker permission allocation)
I have not extensively used schemas, but I can see their worth for organizational purposes and security (even if they may not be now). Especially in apps that have "modules" that you pay for separately, a different schema for each module. Yes, you could do it with different DB's for each module, but I think that makes maintenance harder.
I prefer schemas, but I have multiple applications hitting many of the same databases. A product can be accessed by many applications, and they all want different slices of the data. By setting up service accounts, roles and schemas. I don't have to manage individual object permissions, grant the role access to the schema, and let the developers in each group create objects in that schema. No table access and no permission management issues. We still maintain a naming standard, but the schemas make it alot easier on the DBA staff.
Going off on a tangent, I think schema should be called something else. Maybe not "container", "group" or "family" but something like that. Something that shows that they are logical containers.
I'm saying this because whenever I use the word "schema" I'm almost always referring to the definition of tables sprocs and other db objects as used in the sentence "Changes to the schema require testing, especially for any changing or dropped sprocs"
Fortunately the meaning of "schema" at my workplace is never ambiguous. It always means 'db-object-definitions' We use naming conventions to split things into their domains and everything is "piled under dbo".
Part of the reason is because the db was designed before 2005 and there's no good motivation to change it.
I'd also like to say that I appreciate that everyone in this discussion uses the plural schemas rather than schemata. It reminds me of indexes vs. indices.
…but schemata is the proper plural of schema according to dictionary.com. Are you suggesting that I not use the proper plural because people are unfamiliar with it? Ever seen the movie Idiocracy?
Whatever you do, don't remind them that tables have columns and not fields. I try to be a stickler for using the right words, but I forget from time to time. Schemata included. Although it does sound dumb as hell.
I use words that normal people understand. 😀
My dictionary says the word "schemas" is acceptable. I'm not going to get into a descriptivist vs prescriptivist debate, but I will point out Ben, that you also use words and terms like 'whomever' and 'riddle me this'.
Chacun son gout.
"If they're used right, they let you segregate permissions by groups of objects. But here's the thing – almost nobody ever does that. "
Why is the reason that no one does it right an excuse to not do it at all? LaRock gave this reason for Linked Servers the other day (http://thomaslarock.com/2010/05/what-5-things-should-sql-server-get-rid-of/):
"Seriously, they need to go. Not because they are bad, but because they get abused."
Just because people don't implement it "correctly" doesn't mean that it doesn't have implementations or merits that should be looked at and considered. Which is similar to what someone said about SQLCLR on RunAs Radio (http://www.runasradio.com/default.aspx?showNum=159). 🙂
Personally I have used them to segregate functionality and/or logical breaks but are still dependant on the data somehow. I think a great example of this is CDC, which creates its own schema.
Aaron – that's a great question. I'm of the "keep it simple" school. The more options I can remove, the easier I can make it for not just end users, but for developers who have to maintain the code.
I love your CDC example though. That's an interesting example, and I think it's a great use for a separate schema.
A schema is nothing more than a database inside of a database. Sometimes it makes sense, sometimes it doesn't. What is usually lacking is the 50k foot goal for even discussing their use in the first place.
My frustration with using schemas has more to do with the native development tools. I have seen issues where we grant users access through AD groups and the get back errors when they try to navigate and use schemas. It makes for a very frustrating experience for everyone involved.
Having bought software and later needed reports the vendor was NOT going to add just for me, I am one of those devs who go into the db and pull data on my own. I figure the data is mine so if I need to put my grubby hands into the database 🙂 it stopped being your database when the software shipped. I know in some cases this may violate tos but I think tos should not be legally allowed to keep me away from my own data.
Off topic I know but I had to defend things from the dev side.
Keith – heh, how does that work out from a support perspective, though? For example, according to Microsoft's SharePoint support policy, you're not allowed to touch the database if you ever expect to call for support.
I like using schemata for the very reasons Buck states. I think it's a case of you say tomato, I say tomato…
That doesn't work on the Internet.. but you get the idea.
An interesting discussion. Schemas could be 1) a tool for developers, in which case I agree with you Brent or 2) a tool for DBAs for security. I personally like the use of 2). I don't like them being used as a grouping technique or naming convention, unless that grouping will have distinct and GLOBAL security needs.
One scenario I use it in is in smaller shops where there is only a "Dev" server, or no "Dev" server (yes, those exist!). I'll create at least 3 schemas – one meant as a playground, where the development staff has DBO rights, one for real development work – usually senior staff have full rights – (where unit testing and the like should be done), and a TEST/QA environment, where the developers have no access (only the QA people). As the code gets developed and moved into testing and finally QA, the DBA only has to move objects in between schemas. If QA rejects some code, the DBA just moves it back down. Very handy.
Security is where I think schema usage is appropriate, and that should be controlled by the DBA.
SQLRockstar said what I was going to say: Schemas are another layer of abstraction in the object model.
When designing databases I usually use schemas. I like the organization they bring to the design. Microsoft needs to update some of their management functions/procs to support/manage/report schemas better. Even though they are difficult to support, there are valid business intelligence use cases for doing exactly what Stef Bauer suggested earlier (multiple schemas containing objects of the same name).
After the application and database mature, I sometimes look back and think "Schemas were a waste here." In the database development world we call this "20/20 hindsight."
:{> Andy
Andy brings up a great point, the BI world is one place schemas do well. At PASS last year Eric Veerman showed some examples where he'd created a Fact and Dim schema rather than naming everything dbo.Fact…
After some discussion with him I decided to try this on a project and it worked very well, it also made it easy to have Staging, Log, Temp etc schemas. It made it much clearer what tables did what.
In addition it also made security much easier, for most tasks we only granted rights to Dim and Fact, leaving the other tables only exposed to the ETL processes.
For those schema lovers, how many of you also apply schemas to other database objects (views, sprocs, etc)?
Robert – you're saying to have staging, log, and temp data in your production data warehouse database? It's already hard enough to back up data warehouses and do high availability for them – why put these objects inside the production database? Why wouldn't you have separate databases for these databases that have throwaway data that you don't want to back up so fast?
In ETL scenarios, the words "temp" and "staging" can have different meanings than in other contexts. A common design pattern involves using a Data Flow Task to land Updated Rows somewhere near the destination database – a different schema inside the Production data warehouse database is an option – and then performing a set-based update from a subsequent Execute SQL Task. That would be a good use for a staging schema.
As for a temp schema, SSIS doesn't lend itself to using temp (# or##) tables, and sometimes you need those. One solution is to create a temp schema somewhere – and this can also be in the Production data warehouse database – and materialize ETL "temp" tables there.
:{> Andy
Andy echos what I would have said had I not been stuck in a meeting all afternoon. In addition, I should clarify Log is not a log in the sense of the transactional log but more a specialized ETL history log that holds stats about the ETL execution process. That kind of data is often retained for long periods of time for analysis to determine run times, help with performance tuning, etc. In some cases it also provides proof to auditors that our ETL process ran on a regular basis since management made decisions based on data in the warehouse. (And buddy, you just try telling an inspector from the Nuclear Regulatory Commission you don't have some data they request? Not a pretty sight.)
As for putting Temp and Staging in a seperate database, yes that is an option, but often I've run into issues where we were only allowed one database. Usually it was some sort of cost allocation reason where projects were "charged" (by a central IT group) based on the number of databases they had, the thought being the more databases you had the more of a DBA's time it would take. I'm sure we've all run into situations where decisions are not made based purely on technical merit but some company political or cost rule.
Excellent post though, seems to have really set off a firestorm of debate. I admit I'm learning a lot by the back and forth of the comments here.
Another reason for NOT using schemas are that if you have a schema that is owned for a user, and then later you want to migrate this DB to another server and want to recreate the user you can't drop the user because it owns a schema:
You get this:
Msg 15138, Level 16, State 1, Line 1
The database principal owns a schema in the database, and cannot be dropped.
So, you have to change the schema's owner to anyone else, so then you can drop the user.
But guess what??? If you granted permissions in the schema to any user (Select, exec, etc) these permissions are lost when you tranfer the owner to someone else, you have to transfer the ownership to anyone else, drop the user, migrate the DB, create the user, transfer ownership again to this user, and grant again all other permissions that you lost when you first changed the owner.
This ends becoming an administrative nightmare for a DBAs, In fact, I had to make a script to check if a schema is owned for anyone else different than sa that I run every day in all DBs, to avoid future headaches.
I was one of the MSFT PMs who worked on schemas during the Yukon time frame.
If I recall correctly, goals were (in no particular order):
a) Give developers the convenience of having separate namespaces in a single database.
b) Simplify permissions setting for all current and future objects my GRANT-ing at the schema level.
c) The "WinFS" team asked us for them
d) Better ANSI/ISO SQL compliance
e) Needed for the new "sys." schema
f) Make it easy to drop users but leave behind the objects they owned (had several customer requests for this). Similarly, it is easy to transfer schema ownership.
g) Allow schemas to be owned by a role
h) Allow users to have a specifed default schema (+ modifications to the TSQL name resolution algorithm to make the default schema part of the search path).
Thanks for the insight Clifford, as an occasional developer myself I'm a fan of A. And as someone who gets into debates with others over the merits of SQL versus other DB platforms D is always helpful.
In our large enterprise (hundreds of SQL servers, thousands of SQL databases), our SQL 2000 environment was extremely difficult to control and maintain, especially when it came to security. We refer to it as our "Wild, Wild West"
Because of the problems we encountered, we implemented some pretty strict policies for all SQL2005+ databases developed in-house:
1. All objects have to be under a named schema. No DBO objects at all.
2. All security is set to AD groups at the schema level, with a fairly narrow set of options (pre-defined "webuser" permissions vs "developer" permissions, some exceptions allowed on appeal)
The main thing that it does is force our dev teams to at least *think* a little bit before they implement their schema and security, or when they upgrade a database.
Sure, for fully 50% of databases, that means a single named schema "Appname" that contains all objects, but it still makes it much easier for the DBAs to monitor our policy via scripts.
We have a system which is built on top of legacy database. We decided to use schemas to separate 'new' objects from 'old' objects, which in vast majority are in dbo schema.
At first teams were reluctant to adopt idea of creating schemas in the new system, mostly because of the assumption that schemas = users. Once they were convinced that they are really namespaces, using schemas became very natural. I agree, in homogenous system which is not accessed by end users tweaking security on schema level is not what is done very often.
We introduced schemas to divide objects into some business oriented groups so it is easier to understand their purpose and meaning of the data in them.
I wish management studio could display database objects groupped by schemas, for databases grew a lot for last 7 years, and management studio did not change the way of navigation – it is terribly lame to scroll hundreds or thousands of objects and wait for the tree to populate the leaf data.
schemas are good for many things. We pull data from DB2, which has "libraries" proddta, devdta, stgdta, etc. I have found that using schemas in a SQL DB map nicely to those. I can have 3 schemas with same tables in db, one SSIS package that works on all, just a different schema. Yes of course could have 3 different db's on my end, but that is 2 more databases to backup, manage, etc, etc.
I would use schemas more if there was a way to backup an individual schema's objects without having to resort to segregating it to a different file group. Sure would be cool.
Jason – yeah, agreed. See, that I could really use. That, or the ability to have different recovery models per schema – I wouldn't care about logging in my staging schema, for the examples Andy Leonard sited where he puts staging data in the production database.
I think I smell an MS Connect issue. Who wants to submit it?
For the way I tend to use SQL Server (mainly data warehousing) I'd say that schemas are more of an extended naming convention than anything else, I generally have more databases (DEV/UAT/PROD) or use naming conventions (e.g. fct_table, dim_table, arc_table, stg_table).
That said, I did some work at a hosted application provider who would build many short-term-use (but sometimes reused over time) applications for their clients. For security and convenience (reusing the same table names) developers would create an entirely new database for each application leading to us having literally hundreds of databases on their servers. The perfect solution to me would have been to have one database per customer and then one schema per application and since developers tend to like copy/pasting you could even configure the schema once at the top of each ASP script to make it easy to re-version code and database in a stroke.
We have a database that stores tables, views and procedures that are used for reporting against a 3rd party application. I've used schemas to keep objects in logical groups (like those related to business metrics). I've also used schemas to group objects by the people who have request them so that I can remove objects when the people who have requested them leave.
Count me among those who like schemas. We primarily use them for namespaces within an application's database and for easier management of security, like others have mentioned. Yes, you can do both of those with other methods (and we do have them on legacy apps), but I find schemas a clean way to implement both.
To control the "schema sprawl" that some have mentioned, we lock down permissions so that only DBAs can create schemas, and no user-specific schemas are created.
Having a multiple applications in the same database i see the necessity of using different schemas. Schemas give such a good option of a logical content separation, and doing it the old and not so good SQL 2000 way is something that i do not wish to encounter again.
Same applies for the security reasons – it is so much easier to manage the access to the collection of objects, and those who are starting out have much less probability of executing a wrong action.
I'm not sure I understand the idea of using schemas to separate multiple applications in the same database. If the applications do not share any data (tables) or objects then why would anybody ever put them in the same database? If they do share data (tables) or objects then which schema do the shared items belong in? Is there a "Shared" schema? What if there are three applications and some items are shared between only two of them?
In a couple of my presentations which cover this, I talk about the usefulness of schema. First and foremost is to use the same way we use namespaces in Java, .NET, etc. The security is secondary. But if you can group objects logically, then it works well. I've got some sample code which shows a cabin registration system for state parks… based it on my experience with the South Carolina state park system and who can do what. I really need to write up that SQL Server Standard article…
I grew up on Oracle 8 and 9. In my history, we sometimes stacked multiple applications into a single Oracle Instance seperated only by schema. Outside of the simplified security of using schemas in this model, we could also "pull" an application out of this shared database and into it's own database if the need arose.
SQL Server doesn't really need to worry about this type of model, since it's so easy to just creat a new database, and the licensing of multiple instances on the same hardware. So to me, using a schema to federate logical objects into their own namespaces or domains just doesn't make much sense.
Ok after a serious and funny read of all the posts above, I can write my opinion/way to proceed.
I started with SQL Server in its 2000 Version, where schemas were embryonic and in some cases a nightmare. So when things changed with 2005, I've never felt the need to use them. If I've the need to add an abstraction layer, I use Databeas Roles, Stored Procedures whose execution is granted to this or that Database Role. I think I have the same Brent thoughts: "keep it simple"
As someone said above, I'd appreciate much more Schemas if I could manage schema backup, but I'm so confident with Filegroup/File Backup that this sholud be an option for DBAs are currently using Schemas.
I have to manage issues harder than Schemas, like poor designed Databases, data consistency, poor performances, so I don't want to add a layer to be managed.
1) Having bought hosting before for small companies, and wanting a MSSQL db, those on a shoestring budget, can often only have on database. This si where schema's start coming in very handy
2) Logical organisation of tables and other objects is paramount for me. Coming froma non-technical background I shudder when I see tables like [Application]_[ApplicationModule]_[ObjectType]_[Entity]
3) Again, coming from a non-technical background I'm loathe to do things like cross-server and cross-database queries. It strikes me that data you need should all be in one database. Schemas then allow for logical, but not physical seperation of data.
4) As I work in BI, I have worked in companies with multiple departments who all perform ad-hoc analysis and modelling from the database. In these instances, it is useful to allow every read-only access to tables in a central schema and give them unlimited access to a team schema which they can create tables in, produce stored procs etc. This is also useful for audit purposes because it allows people to keep results stored for a period of time without cluttering up the important tables.
In summary, I like schemas because they allow a logical seperation of data and make development easier.
Our team loves schemas. Below is an excerpt from our BP (for BI datamarts). We generally use a 3-4 layer approach (staging layer, data warehouse layer, optional integration layer and presentatino layer. We also add a schema for procedures that support reporting only. Naming conventions without schemas add clutter to the name. One comment above – using databases in lieu of schemas – this means more databases on a set of LUNS (more potential for I/O contention).
Our guideline:
There are gray areas as to what schema should be used for views, procedures and functions. The design considerations are based on function of object and security considerations for access to schema. Here are some general guidelines to use during application design.
1. Views can support selecting data for reports or aid in loading tables. Views in the data warehouse layer support loading integration layer; views in integration layer support relational reporting from integration layer and loading presentation layer tables. Views should not be used in the presentation layer. As a rule data should be persisted in tables in all layers and views are to assist reporting and data loading and are not intended to replace the function of the architectural layer.
2. Stored procedure that change persisted data should use the schema of the objects being changed. Stored procedures (utility in nature) that cross layers should use the [dbo] schema.
3. Stored procedures and functions for reporting (no change to persisted data) should use the reporting schema (rpt).
Exceptions to the above guidelines would be based on security requirements where exposure of underlying data needs to be restricted based on role.
I've used schemas for small projects that may well get integrated into an existing DB. Imagine writing the latest and greatest forum software – nice to create your our schema and if they want to integrate all is separate and clear, and if they decide to stick to a separate db, that works too. But it's still one schema, just not dbo!
Andy – now I like that idea. That makes perfect sense to use a separate schema there to avoid problems like table name overlaps and versioning. I like it.
At our company we have an application where each customer has a seperate database. We are thinking or trying to reduce the number of databases by creating a seperate schema per customer.
The thing is, the permissions stuff is OK it is just the deployment and management that looks very hard.
i.e. New customers happen all the time. at the moment we just restore a copy of the BASE database and rename it. Backups and restores are fine as each customer has their own database.
If we move to a schema per customer then we would have to generate a script (on demand as the system changes all the time) for a Base Schema. then modify the script to apply it to a new schema.
This then has repercusions for any SP/functions that have hard coded schema or database names.
The final issue is if one ofthe customers (schema) requires their data to be restored back. Very easy if one customer for a database but must harder for the data in a single schema.
Hi Adelio,
The "one schema per client in one database" model can sound good on paper, but in practice it tends to be really problematic. You end up with all the pains of a large, unwieldy database which takes a long time to restore and is tricky to performance tune, but none of the simplicity of shared tables. (In addition to the other issues that you mention.)
Typically you're better off with either the one-client-per-database model or the one-database-for-everyone-with-shared-tables model. Brent walks through those here: https://www.brentozar.com/archive/2011/06/how-design-multiclient-databases/
Personally, I wouldn't take the "one schema per client in one database" approach, but at least the schemas have meaning with this use case as apposed to attempting to logically group tables using schema names.
(Apologies for practicing necromancy. Hello 2014!)
I wrote an app for my company, and was soon asked to deploy a second instance of it, followed by several more. So I took all instance-specific data and put it into separate schemas, keeping global data in dbo. So for each instance, I have a set of tables with the same names and structures, differing only by schema qualification.
On the application side, I removed schema references in queries and had each instance connect to the database with a different user whose default schema was set to the one corresponding to the instance.
This system has worked really well so far. The only drawback is that a couple of recently added use cases require having data that refers to multiple instances/schemas, which case I had to choose between losing FK/referential integrity, denormalizing, or collapsing all the instance tables into dbo, with instance ids added to all the primary keys.
I think it is nothing more than a design principal. If I take an example of Class or Interface, I can put all my functions or logic at same place and everything will work well, you can do any dam which you can do by separating your logic into different class.
Similarly, I can do everything without schema but it's just different design approach to have it, I don't see any other point…
I have been working on schema base security and found something a little confusing. I have 3 schemas Common, Messaging, and Ordering (schema_id 4 – 7). When I look in sys.objects I see the names of Common and Ordering as sysrowsets and sysallocunits. This is based on the object_id matching the actual schema id and a type of "S". What I do not see in sys.objects is the object_id which matches the schema_id for Messaging and there is not an object_id of 6. It is in sys.schemas and I can do what I need to do for the task. I was just wondering why there would be no reference in sys.objects and is "Messaging" some kind of key word.
There is nothing more entertaining than watching a room full of developers try to find a [Vendor] table in the SSMS tree, only to finally discover it at the top of the list in the [profile] schema.
They make modeling more difficult, they play hell with Entity Framework, SMO become more tedious and I've seen tables grow out of their schema. For example, a [static] schema table that receives updates.
Schemas are not folders, please do us DBAs and Database developers a favor and avoid using them as such!
Josh – I think, if I tried hard, I might be able to think of something more entertaining. 😉
Hi Brent! Now I feel bad dragging you back in to the past.
Truthfully, I came up with something more entertaining at some point – but I cant recall what it was.
I use different schema in my staging database for my source tables, one schema for one source and my tec tables with tec that represent all intermediary tables and process in order to fill my staging dbo tables that are the respresentation of my presentation layer.
I also use schema when I need to separate objects from their use.
Stored procedure for reporting, …
These objects have specific use and so will not be used in other context.
This is to allow fast answer time to bug and failed process.
Of course It needs to be weighted and not create a schema for everything and also considering objetcs that might be used in a mixed situation…
when you have a staging with a lot of table from different sources, this help the whole process.
Surely (ha) you can take your lead from Microsoft with the dbo. sys. and INFORMATION_SCHEMA. schemas. Sometimes MS themselves use prefixes on the table to separate things and sometimes they use a schema.
Looking at their use of schemas, they seem reserved for 'grand concepts' rather than simple groups of like tables and also as people have said likely security divisions.
…and referencing comments above: You can grow out of a logical table group but you rarely grow out of a 'grand concept' There is always a place for an info schema and always a place for system objects, that do not really cross the 'normal' tables and the division between them is well defined.
Not sure that there is a "higher" scheme at microsoft. They are composed by many team and each one has it's own rules…
For example 10 years ago, we saw 2 "example" db coming into sql server… Pubs and adventureworks… Simply because they had decided that ms access would disappear, they had assigned the ms access team to sql server and they compete each others saying their example db was the best…
There are other example where you can see that they put things together without any common idea…


text:
When Lexus brought in a five-speed shifter for the IS300, there was general approval from those of us who thought the car would make a fine sports sedan with the right transmission. Now we're thinking it just needs more power.
Not that the straight-six in the IS isn't a great engine--it is--but more would be better. As it is, the Lexus runs the second-slowest 0-to-60 sprint in this group (at 7.3 seconds) and the third-slowest quarter-mile time. At least it doesn't feel weighed down by too much luxury equipment, scaling in at a reasonable 3380 pounds and steering adroitly.
If anything, the Lexus feels small--particularly to six-foot-something drivers, who find the cockpit almost like a seven-eighths-scale model, mainly due to a smallish seat and a nontelescoping steering wheel. But editors of average height considered the seating position entirely satisfactory and scorned that assertion.
Lexus's choice of interior décor is highly original. Eschewing clichéd sport trappings such as dual gauges and leather-wrapped gearshift knobs, Lexus chose the curious chronograph-inspired instrumentation and chrome-gearshift-ball approach.
It works well on this bijou sports sedan, falling in line with the car's particular priorities. Which are, if we're not mistaken, to blend Lexus's incomparable levels of isolation with a sporty sense of involvement. Yeah, that's almost a contradiction in terms, but the result is quite good. The IS is quiet, almost too quiet. We'd like to hear that sweet inline six sing a little louder, please. And its controls are light and slick, but not to the point of complete detachment.
Gear selections are clearly felt, and the steering is crisp, but the fly-by-wire throttle is as slow and distant as a ship's telegraph. It improves when on the move, but revving up for a drag-strip launch feels weird and artificial.
When cranking this little jewel through the wiggly sections of our test course, most drivers found the car willing, stable, mostly responsive, and without serious vices. Some considered it softly sprung and too prone to roll, but other than lifting off its wheels and showing us some space between inside tires and wheel arches during skidpad testing, these characteristics did little to hurt the car's handling.
With an optional Torsen limited-slip diff ($390) stopping inside wheelspin in turns, the Lexus circulated our test track without drama and aced our lane-change test. As one editor wrote: "The IS300 is a delightful welterweight in a middleweight shootout." As such, fourth is a worthy result.
Recent News


text:
KIEV, June 19 (Itar-Tass) - Ukraine's parliament has not approved a draft law to denounce the 2010 agreement to extend the stay of Russia's Black Sea Fleet in the Ukrainian port of Sevastopol.
The draft law has been submitted by the opposition deputy, Vladimir Yvorivsky. A total of 152 deputies voted for the draft law.
According to the opposition, the agreement with Russia was signed and ratified "in detriment of Ukraine's national interests". "It poses a potential threat to the country's sovereignty and its territorial integrity," the opposition said.
Deputies of the Party of Regions faction and the Communists disagreed with this position.
Earlier, the parliament's committee for international affairs recommended to reject the draft law because it violated several Ukrainian laws, as well as the Vienna Convention on the Law of Treaties.
On April 21, 2010 Ukrainian and Russian Presidents, Viktor Yanukovich and Dmitry Medvedev, signed an agreement to extend the stay of the Black Sea Fleet on the Ukrainian territory till 2042. On April 27, 2010 the Ukrainian ratified the agreement.


text:
The Art of Coffee original egg tempera painting by artist Linda PaulBeautiful original sculpted painting of coffee beans, burlap bags, coffee plants and Hawaiian Kona flowers, coffee grinder and biscotti cookies all overlooking a tropical plantation By American artist Linda Paul. Free shipping in USA and to Canada
$ 949.00
Size 29" wide x 25" high"
Questions? call 800-936-9958
copyright info will not appear on the original art that you purchase. Painting is signed by the artist
Artist's Inspirations: I love coffee! Couldn't paint without it. If I was ever on Survivor, and they allowed me to bring one luxury good, it would have to be coffee! Combine that with my desire to live somewhere tropical like Hawaii and the inspiration for this painting was born. I imagined a window overlooking a misty coffee plantation with a volcano in the background, hanging coffee vines, burlap coffee bags some cool coffee cups, a grinder, and of course biscotti cookies and a Hershey's chocolate kiss that goes oh so perfect with coffee. I wanted to portray that coffee is an art and a beautiful process from the field to your coffee cup.
So as usual, I am not sure what
colors I want to use in this painting, so I decided
to do a little study painting of the burlap coffee
bags and hanging coffee plants. At first I had the
background sky a slate blue, but I did not like the
cool tone it cast, so I changed it to a latte
coffee color. Color is all about what color in next
to it rather than the color itself in isolation.
background first and then move forward. The background will be a tropical landscape of rich vegetation, a plantation house and faint volcano. My next step will be to layer mists onto the dark green vegetation, softening the lines and creating the feel of a misty, tropical morning
You can buy The Art of Coffee as a print on canvas
You also might like these coffee inspired works of art by artist Linda Paul
Questions? call 800-936-9958


text:
Steve McClaren has hailed Fabricio Coloccini as his "signing of the summer" after revealing just how close Newcastle were to losing their captain.
The head coach was almost resigned to losing the 33-year-old, with offers on the table from elsewhere, until a contract extension was agreed to keep him at St James's Park.
They've done that, and deep down, I think he always wanted to finish his career at Newcastle.
Coloccini – who has endured a difficult start to the new campaign – was outstanding in the goalless draw against Manchester United at Old Trafford.
And McClaren admits he was delighted Coloccini agreed to stay until the summer of 2017 – given none of his possible replacements matched up.
"There was a point in the summer where we thought he (Coloccini) might well be going. Most definitely," revealed McClaren.
"There were offers on the table, but the club has done great to address that situation and keep him.
"We said, 'Sort him out, and get him back on board'.
"They've done that, and deep down, I think he always wanted to finish his career at Newcastle.
"I'm pleased he performed like he did.
"There's been a lot of talk about signings this summer, but for me, that (Coloccini) was the best one.
"We looked around at various defenders when his position was in doubt, but we quickly decided that none of them matched up.
"I quickly said, 'Look, we need to get him back on board' and the club has done that.
"I think his relationship with the club and the seven years he'd already had here were important.
"He's got a real affinity with the club, and I think he just wanted to finish his career here.
"Why not? We've come in, and he's probably had a little look at how we've been operating in the first three or four weeks too.
"He's obviously been happy with what he's seen, but it was also about the club rewarding him, and that's what they've done."
McClaren was also quick to praise the "heroic" defending at Old Trafford from the rest of his backline – including keeper Tim Krul.
But he is still looking for another 20 per cent from his players.
McClaren added: "I thought along with (Steven) Taylor, he (Coloccini) was excellent. I also thought (Chancel) Mbemba was superb.
"He's not a right-back, but he did a gallant job there.
"That back four – five with Tim Krul behind – is going to be important for us.
"You don't come to Old Trafford and get a result if you don't defend well, and that's what we did.
"We conceded two goals against Southampton and two more against Swansea, albeit with ten men, so it was important to keep a clean sheet.
"I thought we were excellent and that performance is a real platform.
"You look at our players and think they're still 20 per cent or so down on where they'll eventually be.
"I look around our squad and think, 'Well he could be sharper, and he could be sharper'.
"It was a short pre-season and an early start, and that's what you're going to get."


text:
Entering into the small land locked country of Himalaya, the uniqueness of its culture and tradition will identify the lives of all 7 lakhs people.your journey to Bhutan will experience the unforgettable memories of seeing different types of habitations, living styles of people and exercising of Gross National Happiness at individual level.
Start Planning Your Bhutan Tour Today.
Here are just a few of our up coming events suggested tour itineraries.
The Dochula Druk Wangyel Festival was established in 2011 in commemoration of His Majesty the Fourth Druk Gyalpo and the Armed Forces' victory over Indian insurgent forces residing in southern Bhutan in 2003.
The crystal clear rivers of Bhutan are one of the kingdom's best kept open secrets. Fed by the glacial-melt of the Eastern Himalayas, six major rivers (Wang Chhu, Sunkosh, Puna Tsang Chhu, Mangde Chhu, Kuri Chhu
Bhutan is a paradise for bird lovers and ornithologists. Over 670 species of birds have been recorded and many more are yet to be discovered. Around 50 species of the known birds are winter migrants.
This is a short and easy trek through Punakha, the ancient capital of Bhutan. The altitude of the trail covers almost a thousand meters in range
Punakha is located in the western part of Bhutan is the winter home of the Je Khenpo, the Chief Abbot of Bhutan.


text:
StateUniversity.com lists the Fashion Institute of Technology as the only college that offers a specific major in fashion modeling. FIT is a campus of the State University of New York. The admissions process of this college is highly selective, requiring an application, academic history report, entrance essay and portfolio.
While numerous colleges offer majors in fashion design, fashion studies and fashion history, modeling is a subject rarely offered as a primary or secondary major. As of 2015, the Fashion Institute of Technology offers associate, bachelor and master degrees in a variety of subjects in the field of fashion, including interior design, fragrance production, fashion management and illustration.
A total of 39 students graduated with a fashion modeling major in 2012, shows StateUniversity.com's student graduation demographics. The estimated total cost of on-campus attendance for this college is listed at $20,616. The highly selective nature of the admissions process leads to an admissions success rate of 43 percent. FIT features an enrollment total of 10,225 students, with a student-to-faculty ration of 30:1.
The Fashion Institute of Technology features several alumni that are famous in the fashion industry. Examples include fashion designer Calvin Klein, shoe designer Brian Atwood and fashion journalist Nina Garcia.


text:
Manuel is a truckdriver in his forties. When he sees fifteen-year old Ana, it seems to him that there has never been anyone in the world so beautiful or desirable. He is overjoyed when she agrees to join him at his home, but her cooperation when he locks her into his attic is not quite so freely given. This drama is based on a 1960s stage play by Fernendo Cuadra).
Add this movie to your queue to receive more information about
La Nina En La Palomera and we will let you know when it becomes available.


text:
Beatriz is a passionate and creative violinist and teacher based in London. She entered the prestigious Conservatorio Superior de Musica de Aragon at the age of 17, completing the Bachelor degree with Pablo Suarez, leader of La Scala of Milan. She has participated in masterclasses with Nicolas Chumachenco, Massimo Quarta, Catalin Bucataru and The Wihan Quartet, among others.
Beatriz studied quartet with Cuarteto Quiroga, and is currently a member of the highly active London based Isbilia Quartet. She completed her Masters Degree at Trinity Laban Conservatoire of Music and Dance, in London, with M.B.E. Professor Michael Bochmann, obtaining a Distinction. Beatriz is grateful for the support of Trinity College and Margaret Harris Scholarships. As of September 2015, she is studying a Postgraduate Artist Diploma under the tutorship of John Crawford. Beatriz is keen to explore new directions including a violin duo, Duo Realia, with violinist Kieran Burling, whose aim is making chamber music more accessible and exciting using video and social media to engage with a wider audience.
Born in Spain to English and Spanish parents, Cristina started studying as a cellist at the age of four with Javier Albarés, the principal cellist of the Spanish Radio and Television Symphony Orchestra, along with other teachers in her town for several years. At the age of 12 she moved on to Madrid and had lessons from David Peris, teacher at one of the principal music conservatoires in Madrid. She has also been involved in several orchestras such as the Youth Orchestra of Malaga and the Orchestra of Castilla la Mancha performing concerts around Europe and worked alongside to cellists like Alexander Osokin, Asier Polo or Arnau Tomas, the main cellist in the Casals quartet.
She is about to graduate Trinity Laban Conservatoire of Music and Dance, working with David Kenedy throughout these past years. Now she has accepted an offer for Royal College of Music to continue her studies for a Postgraduate course. She's an active player in a wide range of genres from jazz to session music, recorded Cassado's cello suite in 2014 among other projects.


text:
Last year, I wrote about cancelling my home phone line with our local provider and replacing this home service using the wonderful "PBX in a Flash" software on a server located in my house. The original article details the process and hardware utilized. Of coarse, the overall goal of this project is to cut home phone service costs, provided better phone service. My wife Heather LOVES receiving voice mail messages on her computer via email.
In practice, there are a few draw backs to the the setup. The good news is that there are solutions to every problem.


text:
Monday, 21 February 2011
Hello Spring!
10 comments:
Ole Pal, these are some of the most videos and flowers i have ever seen. The site looks great and will come back often to smell the flowers of spring and summer... Will get you linked as soon as i can...ReplyDelete
Good grief, most beautiful , i meant to say...haaaaReplyDelete
Thank you Judy and you are welcome at anytime!ReplyDelete
I had goldfish like that but alas i managed to send them to the great pond in the sky...I love to watch fish swim around, it's very soothing...ReplyDelete
Colin, you have a beautiful blog here. I love the way you have it layed out. Such beautiful flowers and garden .. a true labor of love, I can see. By the way, Judy not only sent her fish to the great fishpond in the sky .. she gave me and David a couple of fish .. dropped one on it's little head when she was dropping it into the fishbowl. Not long after that, it started swimming to the middle of the bowl .. stopped .. and proceeded to swim backwards. I watched him (his name was Finny), for a few days, and then one day he just turned on his side and there was no more swimming for poor Finny.. He had bigger fish to fry, in that fishpond in the sky. haha I still have Minnie, but I don't let Judy anywhere near her. hahahaReplyDelete
Quite right not to let Judy anywhere near Minnie as you could have a minnie disaster on your hands Gerti. Glad you like the blog and thank you for dropping in.ReplyDelete
Colin, I love visiting your blogs. I always get a feeling of peace and tranquility. I can almost hear the birds singing and smell the sweet aroma of all those beautiful flowers. I can feel a gentle breeze stirring the leaves and the warmth that only the SON can provide. Lovely place to be, dear friend .. simply lovely!ReplyDelete
Thank you Gerti for all the lovely things you have written. My garden is nothing special but it is my garden and I love being in it. I try my best in all my blogs and everything I do. You are most welcome anytime Gerti.ReplyDelete
Well, Colin (Judy's ole pal), you not only try, you succeed at doing your best. You have "Quality" written all over you, my friend! And like Arnold Schwarzenager "I'll be back".ReplyDelete
Thank you Gerti and you dont have to keep putting your comments in here or you will end up like me on your blog until you sorted it out! Stick a comment in the top of page posting if you like.ReplyDelete


text:
Big G Cereals are part of the General Mills trusted cereal brand. Start your day with a healthy dose of whole grains, vitamins, minerals, and fiber with each delicious spoonful. Catering to children, young adults, and adults from all walks of life and different health concerns, Big G Cereals caters to your dietary needs. Big G Cereals include dry cereal, family favorites: Wheaties, Total, Multi Grain the different variety of Cheerios, Chex and Fiber One . Big G Cereals make breakfast fun with box top collections, toys in the box, mazes on the back of the box. Breakfast is the most important meal of the day and we have the manufacturer coupons you need to make sure you are getting your daily dose each and every morning.
Big G Cereals Coupons
Printable Big G Cereals Coupons
Available Everywhere!
$1.00 off any 2 Big G Cereals
Expires: 01/30/2019
Comments ()
You must login first before you can post a comment.


text:
Medium-sized vintage tobacco premium flannel "felt" with the 1912-1959 48-Star United States of America Flag set against a YELLOW background - distributed between 1912 and 1916 as a premium with one of the several cigarette brands marketed by the American Tobacco Company, as one of several sets of "Flags of the World" series issued with different tobacco brands. This felt measures 5-1/4" x 8-1/4". Full-color image of the flag is on both front and back – however, the side with the hoist to the left is the "front" or better side.
The 48-star flag, arranged in 6 rows of 8 stars each, was adopted when two stars were added for the new states of Arizona and New Mexico in 1912. This remained the configuration until July 4, 1959, when an additional star was officially added for the new state of Alaska, bringing the total number of stars to 49. On July 4, 1960, the current 50-star flag was officially adopted when Hawaii was also granted statehood. There are thirteen stripes representing the thirteen original colonies.
On this flannel felt, the 48-star American flag is set against a YELLOW background, and surrounded by a stars-and-bars decorated border. NOTE: The border surrounding the felt is not part of the flag itself, but is common to all felts issued in this particular "Flags of the World" series.0
The practice of inserting premiums in tobacco products began in about 1870 and continued into the first decades of the 20th century. As with the "silks", flag textiles or "felts" were packed in or on packages of cigarettes from 1906 and to 1916. American Tobacco Company was one of a number of cigarette companies that distributed free silks, flannels or leather to customers who purchased their tobacco products as either "inserts" or "premiums". Larger "felts" were available in premium catalogs, and sent to consumers in exchange for coupons distributed in tobacco packaging. This United States 48-Star Flag flannel felt is one of the moderately large ones and could have been distributed as a premium.
Tobacco "felts" were actually made of a cotton flannel fabric and printed in many designs, in themes similar to those used on silks. They were often used by women to make quilts and other textile objects. (It is thought that distributing these textiles with tobacco products may have been a marketing strategy to entice women into smoking cigarettes.) Some subjects also seemingly targeted women, like butterflies, but the majority of the flannel felt themes were male oriented. "Flags of the World" was one of the most popular themes.
CONDITION NOTE: There are five available, each SOLD SEPARATELY. Each is in generally good condition, although the condition of each may vary slightly. Fabric is not color-fast. Three have areas of pink discoloration, and two have small spots of light age discoloration, visible in some spots on the front-side white stripes. On two, the blue field has bled slightly into the white stars. On the back side, some may have small areas of surface wear. There could also be slight wrinkles in the fabric, which should disappear with a careful pressing on delicate setting. The edges of each may be very slightly frayed in spots. ANY FLAWS ARE OBVIOUS IN THE PHOTOS.
6 other shoppers have this item in their Cart or Wish List
ANTIQUE SHAKER Items-Period New England Furniture-Vintage Toys, Advertising & Victorian Trade Cards
HOLIDAY CYBER SALE - Offers Considered on ALL Items - Save $$ with COMBINED Shipping & MULTIPLE Purchases!


text: We stayed 1 night on our way to the coast and 2 nights on the way home. The hotel was easy to access from I-84 and dining and shopping options were an easy drive. It was also easy to access Chinook Landing Park for our salmon fishing charter with Jack Glass of Hook Up Guide service who as great and... More


text:
from Wiktionary, Creative Commons Attribution/Share-Alike License
- n. Plural form of king.
- n. A pair of kings.
Sorry, no etymologies found.
And if he has been training kings for Samavia all these centuries -- they may have been poor and nobody may have known about them, but they've been _kings_.
Wisdom and might are His; and He changes the times and the seasons, and He removeth kings and setteth up kings (Dan. ii.
Articles 19-27. Twenty-Seven Articles Respecting the Reformation of the Christian Estate
The term kings and kingdoms are used interchangeably in Daniel.
Hence the age of the kings is the age of the prophets.
Johnson thus operates in that extended period of English (and American) history when the divine right of kings is not yet quite exhausted or discredited but when the concept of "the rights of man" has yet to be fully born.
The luxuries most middle-class Americans can access through this system surpass the wildest dreams of kings from the past: amazing amounts of food, cars, air-conditioning, etc.
Rebecca R. Scott: Almost Heaven or Almost Hell? Fossil Fuels, Paychecks and Nature
In the front of the crowd were several Eldorado and Bonanza kings from the Upper
For those who believe in kings, Progressive Democracy, additional gun control legislation, and other such folly – serious discussion only comes down to the amount of legal stealing the government can do from the public (taxes). ib
"And Mr. Casey, one of today's junk-bond kings, is in the midst of a run unlike anything Mr. Milken saw from his X-shaped trading desk in Beverly Hills."
"All the inhabitants of the world should know that the power of kings is vain and trivial, and that none is worthy the name of king but He whose command the heaven, earth and sea obey by eternal laws."
The Volokh Conspiracy » Durbin Threatens Visa and Mastercard on Debit Interchange Fees:


text:
Up and down the markets go in a tumultuous week for stocks across the globe. The Dow Jones Industrial Average (DJINDICES:^DJI) has recovered from deep losses today and nudged into the green, helped by Procter & Gamble's (NYSE:PG) big gains. The blue-chip index is up a meager five points as of 2:20 p.m. EDT after suffering nearly triple-digit losses this morning. Still, concerns over the future of quantitative easing continue to spread investor doubt, and most of the Dow's members are in the red. Let's check out what Procter & Gamble's doing to beat back the Dow's losses and why most stocks are falling again today.
P&G soars despite stimulus fears
Today's report of a 3.3% gain in durable-goods orders beat expectations and showed that manufacturers are still succeeding despite tax increases and budget cuts. That wasn't enough to fight off stimulus fears, however, after Federal Reserve Chairman Ben Bernanke's comments to a congressional committee indicated that the central bank could slow stimulus bond-buying later in the year. Easing will have to end eventually, but Wall Street doesn't see it that way yet. Bernanke did caution that slowing easing too soon could jeopardize the economy's recovery, however, so fear over the end of "QE infinity" looks premature.
Procter & Gamble hasn't given in to the pessimism, however: Its stock has gained 4% to lead the Dow higher. The company is bringing back former CEO A. G. Lafley when current chief executive Robert McDonald departs at the end of June. Lafley oversaw P&G's strong growth from 2000 to 2009, and his rehire has ignited investor optimism, which has dwindled over the company's lackluster past few years. McDonald has aimed to cut costs and increase market share during his time, but his efforts to steer P&G out of the depths of the recession haven't been enough for investors. Lafley has promised no major changes to P&G's strategy, but his hire has immediately created a spark.
Procter and Gamble is outnumbered on a Dow dominated by laggards, but no stock is losing so much as Hewlett-Packard (NYSE:HPQ). Shares of the tech giant are down 2% today as part of a correction after yesterday's massive double-digit rise. Earnings beat expectations and sparked yesterday's surge, but investors shouldn't place too much faith in HP's turnaround just yet. The company might be topping Wall Street's projections through cost-cutting, but slumping PC sales still dominate HP's financial woes. Until HP can successfully transition away from PCs into more lucrative areas such as mobile and cloud computing, investors should expect more ups and downs from this troubled stock.
Verizon's (NYSE:VZ) stock also ranks among the biggest Dow laggards, with shares down 1.1% today. The telecom firm released its Verizon Cloud data backup system for iOS users yesterday after launching the app for Android users last month. The app is a part of Verizon's focus on cloud technologies as it looks to solidify its hold on mobile wireless users. The company's partnership with Nokia's Lumia 928 phone should help to attain that goal if the Windows phone takes off and secures a niche outside of Android and iOS platforms.
Fool contributor Dan Carroll has no position in any stocks mentioned. The Motley Fool recommends Procter & Gamble. Try any of our Foolish newsletter services free for 30 days. We Fools may not all hold the same opinions, but we all believe that considering a diverse range of insights makes us better investors. The Motley Fool has a disclosure policy.


text:
LANSING, Mich. — The state Senate on Thursday approved a resolution sponsored by Sen. Phil Pavlov urging the president and Congress to curb and clarify the role and authority of the U.S. Department of Education regarding state and local funding to school districts.
Senate Resolution 214 addresses new federal rules that contradict the purpose of the Every Student Succeeds Act (ESSA), which is to direct more control over education away from the federal government back to local districts.
"The U.S. government telling states and local school districts how to spend their money is federal overreach, pure and simple," said Pavlov, R-St. Clair Township, chairman of the Senate Education Committee, which took up SR 214 on Tuesday. "We don't need any more burdensome federal reporting and mandates on how we fund our educational system."
ESSA requires districts to use a methodology to allocate state and local funds to each Title I school that ensures each of those schools receives at least all the state and local funds it would otherwise receive if it were not considered a Title I school.
The federal government, however, is taking this a step further by dictating how state and local funds may be distributed in schools that also receive Title I funding, which is earmarked for low-income students.
SR 214 points out that under current federal law, the Education secretary may not dictate the methodology a local school district should use in order to ensure the funding in Title I buildings is at least equal to the overall funding in the non-Title I buildings in the districts.
In addition, the Congressional Research Service interpreted federal law as not requiring equalized spending per pupil on a statewide basis, on a school district basis or on an individual school basis.
State Superintendent Brian Whiston testified in support of SR 214 before committee.
"The goal of promoting educational equity is laudable. We support that, of course, Whiston said. "But concerns have been raised that the proposed regulations do not take into account the many factors that affect building-by-building spending decisions at the local level."
SR 214 states that school district personnel have complained that the proposed regulations would be unworkable. The American Association of School Superintendents stated that the proposed regulation "… glosses over the realities of school finance, the reality of how and when funds are allocated, the extent to which districts … have flexibility, the patterns of teacher sorting and hiring, and the likelihood that many students would experience the rule, as drafted, in a way that undermines true efforts aimed at increasing education equity."
The following groups support SR 214:
• Michigan Department of Education;
• Michigan Association of School Administrators;
• Michigan Education Association;
• The Intermediate School Districts of Barry, Branch, Calhoun, Jackson, Lenawee, and Monroe counties;
• Michigan Association of School Boards;
• Wayne County Regional Educational Service Agency;
• Oakland Schools;
• West Michigan Talent Triangle; and
• ESA Legislative Group.
Copies of SR 214 will be transmitted to the President Obama, the president of the U.S. Senate, the speaker of the U.S. House, the members of the Michigan Congressional delegation, and the U.S. Department of Education.


text:
Community Partner Spotlight — Project Open Hand
Founded in 1985, Project Open Hand is a nonprofit organization that provides meals with love to critically ill neighbors and seniors to fulfill their mission to nourish and engage their community.
Every day, more than 125 Project Open Hand volunteers prepare 2,500 nutritious meals and provide 200 bags of healthy groceries to help sustain their clients, as they battle serious illnesses, isolation, or the health challenges of old age in San Francisco and Alameda Counties.
For Seniors and Adults with Disabilities: The organization provides warm, nutritious lunch to seniors (age 60+) and adults with disabilities (age 18–59) at locations throughout San Francisco.
For People Living with Critical Illness: Through Project Open Hand's Wellness Programs, they provide nutritious, medically-tailored meals and groceries for pick up in San Francisco and Alameda Counties. Home-delivered meals for clients who are homebound are offered as well. Registered dietitians support and counsel clients to help them feel better by eating right.
Involvement with the Center
"As we have expanded our services over the past several years, Nora Silver, Ben Mangan, and Jay Stowsky have served as strategic thought partners and an invaluable source of guidance," said Hannah Levinson, a Development Officer for Project Open Hand. "We look forward to continuing our involvement on a larger scale through Social Sector Solutions!"
Project Open Hand has been matched with a diverse team of student consultants in the Social Sector Solutions (S3) program. The organization was also matched in the Berkeley Board Fellows program last year.
Last year, Berkeley Board Fellows conducted a market assessment of the East Bay for Project Open Hand. The Fellows conducted interviews with physicians, community-based organizations, and health services agencies, analyzed the impact of poverty on health outcomes, and made recommendations as to how the organization could address unmet needs in the East Bay.
During the 2016 spring semester, Project Open Hand will work with team of MBA consultants, and the S3 student team to develop a strategic program plan and landscape analysis of hunger fighting organizations in Alameda County. The consulting team will provide a fresh look at the current programs and conduct an analysis of food and nutrition services within Alameda County. The analysis will focus on the critically ill, vulnerable senior population to help the organization adapt its services and maximize its impact.
Advice for MBAs interested in the Social Sector
In the words of Project Open Hand CEO Mark Ryle: "When I started my career at Lehman Brothers in the mid-1980s, I was driven to be the best among some of the best in the M&A industry. 25 years later, I use that same drive to help feed the critically ill and seniors. I found a place where my ambition and heart can work together for a greater good. Look for that place in the world, and you're bound to fundamentally shift the balance and leave a legacy."


text: Hello Pastry Chefs, I want to make a Japanese Cotton Cheesecake wedding cake (small- just two tiers). I'd like to frost it with maybe a boiled frosting or a light buttercream or even a cream cheese frosting. Will the Cotton Cheesecake hold up to a heavier topping other than whipped cream? How far in advance can I make the cheesecake, no frosting? Thanks!


text:
I am a little hesitant to try new slow cooker recipes with pasta in them as they can sometimes turn into goopy messes. But the lure of my slow cooker usually pulls me in, as it did with this recipe.
Tuna Noodle Casserole hasn't been made in my house in a long time because my go-to recipes use a "cream of" soup, so I enjoyed making the white sauce from scratch.
I have started making a list of meals for Lent instead of cheese pizza, and along with Salmon Cakes and Pan Fried Tilipia, this would make an easy meatless meal to put together.
The verdict?
The cooking time on this was right and the consistency was perfect: not too goopy, but still combined well enough to be total comfort food.
I used french fried onions as my topping, as they were leftovers from the Super Bowl (thanks Beth!) and that was a bonus to me! I don't think I would buy them specifically to top this casserole, but it was fun treat. The topping doesn't get too crunchy as the crockpot keeps all moisture inside.
Although the leftovers were still good the next day, I preferred them the first night, straight out of the crockpot.
I'm sharing this at Frugal Upstate's Frugal Food Series: Tuna.
Slow Cooker Tuna Noodle Casserole
Ingredients2 tablespoons unsalted butter
1 cup chopped onion
8 ounces fresh mushrooms, sliced
2 tablespoons flour
1 cup chicken broth (I used homemade)
1 - 13 oz can evaporated milk
6 ounces cream cheese
5 ounce can tuna, drained well and flaked
1 heaping cup frozen peas
salt and black pepper
8 ounces uncooked penne
1/2 to 1 cup of your family's favorite topping: cornflakes, potato chips, or french fried onions
InstructionsIn a medium size skillet over medium heat, melt the butter, then cook the onions and mushrooms until softened, about 5 minutes. Sprinkle with flour and cook for 30 seconds. Add the broth and milk. Bring to a boil, stirring to avoid clumping, until thickened into a thin white sauce. Add the cheese and stir until melted. Add the tuna and peas and stir to combine. Season lightly with salt and pepper.
Meanwhile, cook the penne in boiling water for half of the time suggested on the box. You want the pasta undercooked. Drain and add to the tuna sauce and stir to coat evenly.
Use a medium round slow cooker and coat the slow cooker with nonstick cooking spray. Pour the pasta mixture into the cooker, and cover with the topping. Cover and cook on High until hot and bubbly, 1 1/2 to 2 hours, or on Low for 4 hours. Serve immediately.
Cooking time (duration): 25
Number of servings (yield): 4
Meal type: dinner
My rating:


text:
One of the 'Hot Desk' offices at the Convento di San Domenico
If you find yourself at the Convento di San Domenico with an hour or two on your hands between lessons or meetings, and need a quiet, peaceful place to work, you can use the EUI Language Centre's 'Hot desks'.
These temporary working spaces are called 'Hot desks' for two reasons:
The Hot desk office, office SD 055, is situated on the second floor of the Convento at the terrace end of the corridor, just past the Language Centre Assistant's office.
The office contains three desks and chairs.
You will need to bring your own laptop.
Feel free to knock on Language Staff's doors if you need assistance.
Page last updated on 19 April 2018


text:
And the second segment in this celebratory series takes off...
6) "Happy workers increase productivity, go the 'extra mile' and become willing cheerleaders...of companies' brands, thereby boosting their reputations".
Discussion Forum #2 – What Would Make You Happy At Work?
September 2014
Job satisfaction and employees' happiness at work favourably impact the organisation. Although this discussion was time-limited, candid statements from professionals who posted comments makes this post an interesting read.
7) "Even the most modest effort made by Management to really listen to its staff and to provide what is desired, within reason, communicates a proactive, caring culture".
Management 101: Creating A 'Listening' Culture.
October 2014
A 'listening' culture at the workplace is required for effective management and improved performance. Go back to the basics and get it right!
8) "A good corporate reputation leads to trust in the brand, which leads to increased patronage of the company's products/services, resulting in higher profits for the business".
Boosting Corporate Reputations With Effective Communications.
November 2014
Maintaining a good corporate reputation is essential for the profitability and longevity of your brand. Learn how to leverage strategic communications for the competitive edge. This is a must-read article for Management and communications/PR professionals. It also captures the essence of this blog.
9) "Without good content, your brand is dead. Or dying. Or on its way to its imminent demise".
Leveraging Business Content For Brand Dominance.
January 2015
Corporate storytelling is now indispensable to your business goals. Learn how to use business content to strengthen your brand and get results. Useful tips from content experts such as Copyblogger and Visual.ly are given.
10) "Unless the content adds value to my work, or addresses specific issues, or clarifies some ambiguity about your policies or strategies, I wouldn't care about it...It wouldn't matter what bells and whistles you use or how often you harp on about your plans".
Dear Management: Your Communications Suck!
February 2015
The Employee bluntly reveals why Management's communications fail and gives tips for more effective collaboration with staff. This is another eye-opener of an article for those in C-suite positions.
Thus concludes our third anniversary celebration. Thank you all for supporting this blog since its inception in March 2012.
If you have been a regular reader, let us know your opinions about the blog over the years: Has it grown? How would you rate its articles and the layout/design?
Have you 'stumbled' upon this blog? Let us know what you think and how we can improve your experience here.
Keep your suggestions coming because we really appreciate feedback from you.
Expect changes to the blog this year but don't fret; we will remain committed to providing great content.
Recommended reading
Be kind. Please remember to:
1) Share this article in your social networks by clicking on the icons below.
2) Follow this blog via email so that you are notified immediately a new post is published. You would find details in the blog's right sidebar the homepage.
Need help in writing?
Hire me for a writing assignment, some consulting work and/or coaching sessions in formal writing and communications. There are 2 ways to do this:
A) Send a direct email to: firstname.lastname@example.com.
B) Call for advice and a free consultation:
Nigeria: 0704 631 0592
International: +234 704 631 0592
N.B- First, third, fourth and fifth images courtesy of Stuart Miles; via freedigitalphotos.net. Second image courtesy of Bplanet; via freedigitalphtos.net.


text:
I always like trying out new restaurants and finding the hole in the walls, and what not, so I thought I'd try the new restaurant, Lemongrass Thai and Sushi, and seeing as I've lived in Thailand, I think I know authentic food.
Lemongrass Thai and Sushi – Hwy 70 & OHB, behind McDonald's
Atmosphere – looked very posh compared to the buffet style Chinese restaurant it used to be, the tables were lined up nicely, looked very clean. I only went in for a to-go order, but it appeared they had a station where you can have them cook your food the way you like it. Adequate lighting was nice too, and they had a 92 on their last inspection 😉
Service – Like I said, I was there for a to-go, but it appeared as if the staff was very attentive, they weren't too busy when I went (at 9pm) but there were maybe half of the tables occupied.
Food – Now, I've lived in Thailand, so maybe I'm a little biased, but the food wasn't too bad, I had the Chicken Phad Thai, and I guess I thought it could've used a little more spice and flavoring. I did talk briefly with the head guy there, at least he looked like the manager or owner, and asked him if it was authentic, and he said if it was really authentic, not many people would like it. My take on it is if you're going to a Thai restaurant, you KNOW it's gonna be spicy!!! I'm not even one who really likes the spicy foods, but if my nose isn't running, it wasn't spicy enough. I did also have spring rolls, and they were alright. They give you what they told me was plum sauce, but I don't think I've ever had plum sauce, but it tasted like sweet and sour, just didn't have the consistency of it. Overall, the food was pretty good, I think I'd go back, just need to tell them to put a little more spice on the phad thai. The prices weren't too bad, my phad thai, which was a decent enough portion, was 11.95, and my spring rolls were 2.95. They do appear to have quite the selection of sushi, I'm not a fan of sushi, that I know of, but the sushi lover may be interested in giving this place a try. I would give the restaurant a 3.75 out of 5.
I did, at one point, attempt to start up a dining out group, where we'd meet up monthly, and try different restaurants around, and meet new people in the process, unfortunately, it failed, but if there is anyone interested in doing something like that, let me know, I would love to meet new people and try new things!


text:
Like the Zimmer Tower, the Prisoners' Gate was part of the city fortifications. It dates back to 1375 and was built in Gothic style with classicist elements added in the 18th century. From the 16th century until 1930 it was used as a prison, hence its name. In 2009 the gate was fully restored, it now houses a museum and part of it is used by a hotel
View location in Lier, Belgium.