#Database developer

[fanfenomenon]

hyperfixated on this game so hard i tried to recreate ac syndicate's animus database using html css and js👍

i will make this responsive though, i've only started doing the frontend but i'll also start doing the backend as soon as i finish this

basically this is gonna be a website that will allow you to create a database of your assassin's creed OCs (btw this was inspired by @gwen-the-assassin's idea <33) and help you with worldbuilding and making AUs (i know the ac fanon wiki already exists for that but i wanted to make the experience of keeping a database more immersive u know....)

this might take a while to be completed, but I'll try to post updates on it as much as possible! if there are any programmers/web developers in the ac fandom that want to contribute to this project plsplspls DM me!!

actual pic of the database for comparison:

ik it's not entirely accurate but this is the simplest database in the game that i could recreate lmao

also code snippets just cuz (+ me crashing out)

[pancakeke]

coworkers asked for help and were showing me the details of a bug they found and I immediately locked eyes with the page like a dog catching the scent of its nemesis. I can name the exact bitch causing problems here and I'm sick of this freak coming into my yard.

[walpu]

not to overthink but I find it interesting that Aventurine is the one who comments on Boothill's announcement that goal to find Oswaldo

[daydreamingastronauts]

whatever databases me nd my team are istalling, they are not working(even after following every step carefully) please help if you know any solution to this

[insert-game]

in a lot of ways i feel like i should have gotten a different degree because i feel as an adult my interests are much more creatively driven. but the culture insists that you decide your fate at age 17-19 and then have to stick with it for the rest of your life

[no-more-lies12]

For all the personality disorder friends...

Comment your answer if you picked 'other'!

My goal is 100 to 1000, so I can do some good and basic statistics, help me out please!!!!!

[database-design-tech]

The Great Data Cleanup: A Database Design Adventure

As a budding database engineer, I found myself in a situation that was both daunting and hilarious. Our company's application was running slower than a turtle in peanut butter, and no one could figure out why. That is, until I decided to take a closer look at the database design.

It all began when my boss, a stern woman with a penchant for dramatic entrances, stormed into my cubicle. "Listen up, rookie," she barked (despite the fact that I was quite experienced by this point). "The marketing team is in an uproar over the app's performance. Think you can sort this mess out?"

Challenge accepted! I cracked my knuckles, took a deep breath, and dove headfirst into the database, ready to untangle the digital spaghetti.

The schema was a sight to behold—if you were a fan of chaos, that is. Tables were crammed with redundant data, and the relationships between them made as much sense as a platypus in a tuxedo.

"Okay," I told myself, "time to unleash the power of database normalization."

First, I identified the main entities—clients, transactions, products, and so forth. Then, I dissected each entity into its basic components, ruthlessly eliminating any unnecessary duplication.

For example, the original "clients" table was a hot mess. It had fields for the client's name, address, phone number, and email, but it also inexplicably included fields for the account manager's name and contact information. Data redundancy alert!

So, I created a new "account_managers" table to store all that information, and linked the clients back to their account managers using a foreign key. Boom! Normalized.

Next, I tackled the transactions table. It was a jumble of product details, shipping info, and payment data. I split it into three distinct tables—one for the transaction header, one for the line items, and one for the shipping and payment details.

"This is starting to look promising," I thought, giving myself an imaginary high-five.

After several more rounds of table splitting and relationship building, the database was looking sleek, streamlined, and ready for action. I couldn't wait to see the results.

Sure enough, the next day, when the marketing team tested the app, it was like night and day. The pages loaded in a flash, and the users were practically singing my praises (okay, maybe not singing, but definitely less cranky).

My boss, who was not one for effusive praise, gave me a rare smile and said, "Good job, rookie. I knew you had it in you."

From that day forward, I became the go-to person for all things database-related. And you know what? I actually enjoyed the challenge. It's like solving a complex puzzle, but with a lot more coffee and SQL.

So, if you ever find yourself dealing with a sluggish app and a tangled database, don't panic. Grab a strong cup of coffee, roll up your sleeves, and dive into the normalization process. Trust me, your users (and your boss) will be eternally grateful.

Step-by-Step Guide to Database Normalization

Here's the step-by-step process I used to normalize the database and resolve the performance issues. I used an online database design tool to visualize this design. Here's what I did:

Original Clients Table:

ClientID int

ClientName varchar

ClientAddress varchar

ClientPhone varchar

ClientEmail varchar

AccountManagerName varchar

AccountManagerPhone varchar

Step 1: Separate the Account Managers information into a new table:

AccountManagers Table:

AccountManagerID int

AccountManagerName varchar

AccountManagerPhone varchar

Updated Clients Table:

ClientID int

ClientName varchar

ClientAddress varchar

ClientPhone varchar

ClientEmail varchar

AccountManagerID int

Step 2: Separate the Transactions information into a new table:

Transactions Table:

TransactionID int

ClientID int

TransactionDate date

ShippingAddress varchar

ShippingPhone varchar

PaymentMethod varchar

PaymentDetails varchar

Step 3: Separate the Transaction Line Items into a new table:

TransactionLineItems Table:

LineItemID int

TransactionID int

ProductID int

Quantity int

UnitPrice decimal

Step 4: Create a separate table for Products:

Products Table:

ProductID int

ProductName varchar

ProductDescription varchar

UnitPrice decimal

After these normalization steps, the database structure was much cleaner and more efficient. Here's how the relationships between the tables would look:

Clients --< Transactions >-- TransactionLineItems

Clients --< AccountManagers

Transactions --< Products

By separating the data into these normalized tables, we eliminated data redundancy, improved data integrity, and made the database more scalable. The application's performance should now be significantly faster, as the database can efficiently retrieve and process the data it needs.

Conclusion

After a whirlwind week of wrestling with spreadsheets and SQL queries, the database normalization project was complete. I leaned back, took a deep breath, and admired my work.

The previously chaotic mess of data had been transformed into a sleek, efficient database structure. Redundant information was a thing of the past, and the performance was snappy.

I couldn't wait to show my boss the results. As I walked into her office, she looked up with a hopeful glint in her eye.

"Well, rookie," she began, "any progress on that database issue?"

I grinned. "Absolutely. Let me show you."

I pulled up the new database schema on her screen, walking her through each step of the normalization process. Her eyes widened with every explanation.

"Incredible! I never realized database design could be so... detailed," she exclaimed.

When I finished, she leaned back, a satisfied smile spreading across her face.

"Fantastic job, rookie. I knew you were the right person for this." She paused, then added, "I think this calls for a celebratory lunch. My treat. What do you say?"

I didn't need to be asked twice. As we headed out, a wave of pride and accomplishment washed over me. It had been hard work, but the payoff was worth it. Not only had I solved a critical issue for the business, but I'd also cemented my reputation as the go-to database guru.

From that day on, whenever performance issues or data management challenges cropped up, my boss would come knocking. And you know what? I didn't mind one bit. It was the perfect opportunity to flex my normalization muscles and keep that database running smoothly.

So, if you ever find yourself in a similar situation—a sluggish app, a tangled database, and a boss breathing down your neck—remember: normalization is your ally. Embrace the challenge, dive into the data, and watch your application transform into a lean, mean, performance-boosting machine.

And don't forget to ask your boss out for lunch. You've earned it!

[bellshazes]

getting like a month's worth of emails done today and realizing why people think i'm so busy all the time. if you count all the sub-areas i'm responsible for like they should, as entire categories unto themselves, i think i have easily double the # of my coworkers. and i'm BORED

[jcmarchi]

A Few Ways That Cloudways Makes Running This Site a Little Easier

New Post has been published on https://thedigitalinsider.com/a-few-ways-that-cloudways-makes-running-this-site-a-little-easier/

A Few Ways That Cloudways Makes Running This Site a Little Easier

It’s probably no surprise to you that CSS-Tricks is (proudly) hosted on Cloudways, DigitalOcean’s managed hosting arm. Given both CSS-Tricks and Cloudways are part of DigitalOcean, it was just a matter of time before we’d come together this way. And here we are!

We were previously hosted on Flywheel which was a fairly boutique WordPress hosting provider until WP Engine purchased it years back. And, to be very honest and up-front, Flywheel served us extremely well. There reached a point when it became pretty clear that CSS-Tricks was simply too big for Flywheel to scale along. That might’ve led us to try out WP Engine in the absence of Cloudways… but it’s probably good that never came to fruition considering recent events.

Anyway, moving hosts always means at least a smidge of contest-switching. Different server names with different configurations with different user accounts with different controls.

We’re a pretty low-maintenance operation around here, so being on a fully managed host is a benefit because I see very little of the day-to-day nuance that happens on our server. The Cloudways team took care of all the heavy lifting of migrating us and making sure we were set up with everything we needed, from SFTP accounts and database access to a staging environment and deployment points.

Our development flow used to go something like this:

Fire up Local (Flywheel’s local development app)

Futz around with local development

Push to main

Let a CI/CD pipeline publish the changes

I know, ridiculously simple. But it was also riddled with errors because we didn’t always want to publish changes on push. There was a real human margin of error in there, especially when handling WordPress updates. We could have (and should have) had some sort of staging environment rather than blindly trusting what was working locally. But again, we’re kinduva a ragtag team despite the big corporate backing.

The flow now looks like this:

Fire up Local (we still use it!)

Futz around with local development

Push to main

Publish to staging

Publish to production

This is something we could have set up in Flywheel but was trivial with Cloudways. I gave up some automation for quality assurance’s sake. Switching environments in Cloudways is a single click and I like a little manual friction to feel like I have some control in the process. That might not scale well for large teams on an enterprise project, but that’s not really what Cloudways is all about — that’s why we have DigitalOcean!

See that baseline-status-widget branch in the dropdown? That’s a little feature I’m playing with (and will post about later). I like that GitHub is integrated directly into the Cloudways UI so I can experiment with it in whatever environment I want, even before merging it with either the staging or master branches. It makes testing a whole lot easier and way less error-prone than triggering auto-deployments in every which way.

Here’s another nicety: I get a good snapshot of the differences between my environments through Cloudways monitoring. For example, I was attempting to update our copy of the Gravity Forms plugin just this morning. It worked locally but triggered a fatal in staging. I went in and tried to sniff out what was up with the staging environment, so I headed to the Vulnerability Scanner and saw that staging was running an older version of WordPress compared to what was running locally and in production. (We don’t version control WordPress core, so that was an easy miss.)

I hypothesized that the newer version of Gravity Forms had a conflict with the older version of WordPress, and this made it ridiculously easy to test my assertion. Turns out that was correct and I was confident that pushing to production was safe and sound — which it was.

That little incident inspired me to share a little about what I’ve liked about Cloudways so far. You’ll notice that we don’t push our products too hard around here. Anytime you experience something delightful — whatever it is — is a good time to blog about it and this was clearly one of those times.

I’d be remiss if I didn’t mention that Cloudways is ideal for any size or type of WordPress site. It’s one of the few hosts that will let you BOYO cloud, so to speak, where you can hold your work on a cloud server (like a DigitalOcean droplet, for instance) and let Cloudways manage the hosting, giving you all the freedom to scale when needed on top of the benefits of having a managed host. So, if you need a fully managed, autoscaling hosting solution for WordPress like we do here at CSS-Tricks, Cloudways has you covered.

[racke7]

Sent a message (they have a whole interface for it) to the guys I might have an "in" with for my internship (and updated my resume). Also called the guy running the tiny company that sounded delightful.

The company still sounded delightful, but unfortunately they're basically phasing out because the only one there is like eighty-years-old and he only works on legacy-projects (people with old systems who refuse to update their shit).

As in, listening to him, I kind of get the feeling that he doesn't exactly work 40-hour weeks, but more akin to "a few hours per month". Which obviously wouldn't work for an internship.

Which actually makes me a bit frustrated that I wasn't able to do this career-switch ten years ago, just so that I could do this specific internship. (Don't know how long he's been scaling things back, but yeah)

[bf-rally]

outline of the logo! i decided to use one of my ocs on the side

[angelfrommontgomery]

I forget how different scientists and engineers are. What do you mean you want to meet on zoom for thirty minutes to talk at a high level. I want to look at four numbers for three hours in an office together

[scvnthorpe]

That time I restored a Database view

Recently at work we've been migrating an old database system to a new platform to save money - this kind of shit is what makes your business processes faster, cheaper and more correct - and this has entailed sifting through a lot of tables, views, and views made of tables and views!

As it happens the finance guy who does all the payroll and expenses is a great guy to work with and basically the one person who knows all the relevant business rules, but also basically treats databases like they're excel workbooks. As such you have a bunch of bits stitched to each other and we're just figuring out how to first move everything and then ease into a well-oiled relational model with no duplication and all together on a single database.

While we in the dev team were figuring out how to do this for finance we were recently testing out a modified version of a view built on top of the old version and accidentally deleted the old version and not the modified testing version.

Mistakes are bound to happen, but we needed to figure out how to either restore it or at least figure out how to work without it because finance people love their data views and reports. There are probably clever things you can do with any DBMS to find shit you just dropped and restore it from backup, but I then realised that I'd been tasked with generating all the scripts for the database objects. There had to be a script laying around!

Sure enough I went to dig up the build script for the dropped view, and I ran it.

I queried it, and everything was back in place.

Shit goes wrong sometimes, but having the right failsafes can really make a difference.

Script your shit, use backups, use version control!

[ellraiser]

some older menu designs

[appmasterd]

Top 5 Common Database Design patterns in Laravel

In the world of Laravel development, a well-structured database is the bedrock of a robust and scalable application. While Laravel's Eloquent ORM provides a powerful abstraction layer for interacting with your data, understanding common database design patterns can significantly enhance your development process. 

These patterns not only promote code organization and maintainability but also enable you to adapt your database structure to the unique needs of your application. By mastering these patterns, you can build efficient, reliable, and easily maintainable Laravel applications that can handle diverse data requirements.

1. Active Record Pattern:

This is the most common pattern used by Eloquent ORM in Laravel. It encapsulates database logic within model classes, allowing you to interact with the database using object-oriented methods.

Application

This pattern is well-suited for projects of any size and complexity. It simplifies database operations, making them easier to understand and maintain.

Example:

Advantages:

Simplicity: Easy to understand and implement.

Code Reusability: Model methods can be reused throughout your application.

Relationship Management: Built-in support for relationships between models.

Disadvantages:

Tight Coupling: Model logic is tightly coupled to the database, making it harder to test independently.

Complexity: Can become complex for large applications with complex data structures.

2. Data Mapper Pattern:

This pattern separates data access logic from domain logic. It uses a dedicated "mapper" class to translate between domain objects and database records.

Application

This pattern is useful for large-scale applications with complex domain models, as it allows for greater flexibility and modularity. It is particularly useful when working with multiple data sources or when you need to optimize for performance.

Example:

Advantages:

Flexibility: Easily change the database implementation without affecting business logic.

Testability: Easy to test independently from the database.

Modularity: Promotes a modular structure, separating concerns.

Disadvantages:

Increased Complexity: Requires more code and might be overkill for simple applications.

3. Repository Pattern:

This pattern provides an abstraction layer over the data access mechanism, offering a consistent interface for interacting with the database.

Application

This pattern promotes loose coupling and simplifies testing, as you can easily mock the repository and control the data returned. It is often used in conjunction with the Data Mapper pattern.

Example:

Advantages:

Loose Coupling: Decouples business logic from specific data access implementation.

Testability: Easy to mock repositories for testing.

Reusability: Reusable interface for accessing different data sources.

Disadvantages:

Initial Setup: Can require more setup compared to Active Record.

4. Table Inheritance Pattern:

This pattern allows you to create a hierarchical relationship between tables, where child tables inherit properties from a parent table.

Application

This pattern is useful for creating polymorphic relationships and managing data for different types of entities. For example, you could have a User table and separate tables for AdminUser and CustomerUser that inherit from the parent table.

Example:

Advantages:

Polymorphism: Enables handling different types of entities using a common interface.

Code Reusability: Reuses properties and methods from the parent table.

Data Organization: Provides a structured way to organize data for different types of users.

Disadvantages:

Increased Database Complexity: Can lead to a more complex database structure.

5. Schema-less Database Pattern:

This pattern avoids the use of a predefined schema and allows for dynamic data structures. This is commonly used with NoSQL databases like MongoDB.

Application

This pattern is suitable for projects that require highly flexible data structures, such as social media platforms or analytics systems.

Example:

Advantages:

Flexibility: Easily adapt to changing data structures.

Scalability: Suitable for high-volume, rapidly changing data.

High Performance: Efficient for specific use cases like real-time analytics.

Disadvantages:

Increased Complexity: Requires a different approach to querying and data manipulation.

Data Consistency: Can be challenging to maintain data consistency without a schema.

Choosing the Right Pattern:

The best pattern for your project depends on factors like project size, complexity, performance requirements, and your team's experience. It is important to choose patterns that align with the specific needs of your application and ensure long-term maintainability and scalability.

Conclusion:

This exploration of common database design patterns used in Laravel has shed light on the importance of strategic database structuring for building robust and scalable applications. From the simplicity of the Active Record pattern to the sophisticated capabilities of the Data Mapper and Repository patterns, each pattern offers distinct benefits that cater to specific project needs. 

By understanding the strengths and applications of these patterns, Laravel developers can choose the optimal approach for their projects, ensuring a well-organized, efficient, and maintainable database architecture. Ultimately, mastering these patterns empowers you to create Laravel applications that are not only functional but also adaptable to evolving data requirements and future growth.